Przejdź do treści 
Z strace w systemie Linux widzę na żywo, które Wywołania systemowe naprawdę analizuję działanie mojej aplikacji i dzięki temu znacznie szybciej wykrywam wąskie gardła, problemy z uprawnieniami oraz brakujące pliki. Zamiast niezrozumiałych logów, strace pokazuje mi w kluczowym miejscu pierwsze nieudane wywołanie, argumenty oraz kod błędu – właśnie to znacznie skraca czas poszukiwania błędów.
Punkty centralne
Poniższe kluczowe aspekty pomagają mi szybciej wykrywać źródła błędów za pomocą strace i precyzyjnie je zawężać.
- Przejrzystość: Bezpośredni wgląd w wywołania systemowe pozwala zidentyfikować przyczyny.
- Filtry: Śledzenie wyłącznie określonych plików, procesów lub sieci.
- Analiza na żywo: Śledzić bieżące wartości PID i wykrywać wąskie gardła.
- Porównanie: Porównanie różnych hostów i kompilacji.
- Podsumowanie: Przeglądaj często wysyłane i kosztowne wezwania w zwięzkiej formie.
Krótki przegląd wywołań systemowych
Ustawiłem strace gdy aplikacja zawiesza się, działa podejrzanie wolno lub zatrzymuje się bez wyjaśnienia, ponieważ wynik natychmiast pokazuje mi rzeczywisty Procedura między przestrzenią użytkownika a jądrem. Wiersze zawierają nazwy wywołań, parametry, wartości zwracane, errno i sygnały, dzięki czemu od razu widzę, w którym miejscu dochodzi do awarii. Bardzo często już pierwszy komunikat o błędzie wskazuje prawdziwy punkt początkowy problemu, na przykład wywołanie openat z kodem ENOENT dla oczekiwanego pliku. Jeśli proces się zawiesza, powtarzające się wywołania futex lub polling interpretuję jako wzorce oczekiwania. Dla mnie nie zastępuje to logów, ale uzupełnia je o kluczową szczegółowość bezpośrednio na granicy systemu.
Początek: Uruchamianie procesów bezpośrednio za pomocą strace
Jeśli chcę przeanalizować świeży przebieg, uruchamiam program bezpośrednio za pomocą strace, na przykład za pomocą polecenia `strace ls`, i w ten sposób uzyskuję pełną Sekwencja wywoływanych funkcji systemowych. Za pomocą opcji -e trace=file skupiam się na operacjach dostępu do plików, natomiast opcja -e trace=process pokazuje mi operacje fork, execve i exit. W przypadku operacji sieciowych skupiam się na opcji -e trace=network, dzięki czemu natychmiast rzucają się w oczy operacje connect, sendto i recvfrom. Jeśli liczba wierszy nie zapewnia mi wystarczającej struktury, używam opcji -c i otrzymuję zwięzłe statystyki częstotliwości i czasu. Dzięki temu w mgnieniu oka rozpoznaję, które wywołania dominują w czasie wykonywania i gdzie powstaje wąskie gardło.
Dodawanie i zaznaczanie uruchomionych usług
W przypadku usług, które już działają, korzystam z strace -p PID i dołączę się do tej Instancja, bez ryzyka konieczności ponownego uruchomienia lub przestojów. Opcja -f pozwala mi uwzględnić procesy potomne, co ma kluczowe znaczenie np. w przypadku serwerów WWW i procesów roboczych. Sygnatury czasowe z opcją -tt oraz informacje o czasie trwania z opcją -T pomagają mi precyzyjnie zinterpretować zależności i czasy oczekiwania. Jeśli chcę zobaczyć tylko operacje na plikach, ograniczam wynik za pomocą opcji -e trace=file i zmniejszam obciążenie systemu. Osoby potrzebujące zwięzłego wprowadzenia do przejść jądra znajdą tutaj łatwe do zrozumienia omówienie: Zrozumienie wywołań systemowych, co ułatwia czytanie wierszy strace.
Szybka analiza komunikatów o błędach: pliki, uprawnienia, zawieszanie się systemu
Typowe wzorce rozpoznaję po kilku Wskazówki: ENOENT wskazuje mi brakujące ścieżki, a błędy EACCES lub EPERM wskazują na Zezwolenia, podczas gdy długotrwałe wywołania funkcji futex lub ppoll/pselect wskazują na blokady lub warunki oczekiwania. Jeśli napotkam błędy EADDRINUSE lub ECONNREFUSED, sprawdzam porty i strony przeciwne. W przypadku problemów z TLS lub DNS analizuję przebieg funkcji connect/recvfrom oraz odstępy czasowe między wierszami. Jeśli wywołania funkcji `openat` na ten sam plik powtarzają się bez powodzenia, najczęściej oznacza to nieprawidłową ścieżkę wyszukiwania lub uszkodzoną zmienną środowiskową. Dzięki temu rzadko zajmuje mi dużo czasu zlokalizowanie pierwszego poważnego błędu.
Uwidocznienie struktury czasu i kosztów
Po wpisaniu opcji -c otrzymuję zwięzłą statystykę, która pokazuje mi Akcje oraz częstotliwości wywołań dla poszczególnych funkcji systemu, co pozwala mi określić priorytety dla Strojenie Zauważam. Dodając opcje -tt i -T, rejestruję dokładne znaczniki czasu oraz czas trwania każdego połączenia, co jest na wagę złota w przypadku sporadycznych zawieszeń. Długie przerwy między dwoma wierszami budzą moje podejrzenia dotyczące przerw w operacjach wejścia/wyjścia lub w sieci. Jeśli widzę wiele niewielkich operacji odczytu, sprawdzam buforowanie i dostęp do systemu plików w mojej aplikacji. Dzięki temu mogę celowo wprowadzać optymalizacje, nie działając na ślepo.
Porównania między hostami a kompilacjami
Jeśli coś działa na hoście A, ale nie działa na hoście B, uruchamiam oba procesy za pomocą strace i porównaj to Różnice w przypadku ścieżek, errno, bibliotek i zmiennych środowiskowych. Dzięki temu szybko sprawdzam, czy brakuje jakiegoś pakietu, czy aktywna jest inna ścieżka wyszukiwania lub czy uprawnienia są inne. Jeśli wywołania systemowe, takie jak openat i statx, różnią się kolejnością lub ścieżką docelową, zazwyczaj wskazuje to na odmienny kontekst uruchomienia. W przypadku bardziej szczegółowych kwestii związanych z wydajnością korzystam dodatkowo z narzędzi; ten przegląd dotyczący bpftrace w hostingu pomaga mi jeszcze dokładniej zidentyfikować zdarzenia jądra. W połączeniu strace i bpftrace dają mi jasny obraz ścieżki, jaką pokonuje żądanie w systemie.
Dzienniki mają uzupełniać, a nie zastępować
Czytam dalej Dzienniki aplikacji, jednak strace wypełnia luki między kodem a jądrem, gdy komunikaty są niejasne lub w ogóle ich brakuje, co Wyszukiwanie znacznie skrócić czas potrzebny na ustalenie przyczyn. W kwestiach związanych z bezpieczeństwem chętnie łączę analizę z działaniami audytowymi; każdy, kto systematycznie rejestruje zdarzenia związane z bezpieczeństwem, skorzysta z niniejszego przewodnika: Prawidłowe rejestrowanie zdarzeń w programie auditd. W ten sposób mogę sprawdzić, czy na przykład jakaś reguła blokuje dostęp, podczas gdy strace pokazuje mi odpowiadający jej kod błędu errno. Oba te punkty widzenia dają pełniejszy obraz sytuacji. Ważne jest, aby czas działania strace był jak najkrótszy, aby wynik nie był zbyt obszerny.
Praktyczny schemat postępowania umożliwiający szybkie zawężenie zakresu poszukiwań
Najpierw zdefiniuję Pytanie w trakcie działania: zawieszenie, awaria, błędny wynik lub powolna reakcja, abym mógł znaleźć właściwe Opcja Wybieram. Jeśli uruchamiam system od nowa, używam strace z filtrami takimi jak -e trace=file lub -e trace=network; w przeciwnym razie podłączam się do usługi za pomocą opcji -p. Następnie obserwuję proces tylko do momentu, aż błąd stanie się widoczny, po czym zamykam sesję. Natychmiast zajmuję się kluczowym wierszem: sprawdzam ścieżkę, dostosowuję uprawnienia, testuję punkt końcowy. Jeśli nie udaje się wyjaśnić śladu, rozszerzam informacje o czasie i korzystam z opcji -c, aby wykryć newralgiczne punkty.
Zapisać wynik i przeanalizować go później
Jeśli błąd występuje rzadko, przekierowuję dane wyjściowe za pomocą -o do pliku i za pomocą opcji -ff ustaw podział według PID . W ten sposób oddzielnie rejestruję działania procesów nadrzędnych i podrzędnych. Za pomocą opcji -s zwiększam długość wypisu argumentów, gdy skrócone ścieżki pozbawiają mnie ważnych informacji. W przypadku długich przebiegów ustalam jasny warunek zatrzymania, na przykład do następnego punktu błędu, aby ilość danych pozostała w znośnym zakresie. Później filtruję plik za pomocą grep pod kątem errno lub typów wywołań i błyskawicznie uzyskuję istotne wiersze.
Przegląd najważniejszych opcji programu strace
Poniższa tabela zawiera zestawienie najczęściej spotykanych Opcje oraz ich praktyczne Korzyści razem, żebym nie musiał długo szukać podczas gorączkowych analiz błędów.
| Opcja | Cel | Typowe zastosowanie |
|---|---|---|
| -e trace=plik | Skupienie się na operacjach na plikach | Szybkie sprawdzanie funkcji open/openat, statx i access |
| -e trace=process | Wyświetl działania związane z procesem | Śledzenie funkcji fork, execve, clone i exit |
| -e trace=network | Filtrowanie wywołań sieciowych | Wyodrębnienie funkcji connect, sendto i recvfrom |
| -p PID | Dołącz do bieżących procesów | Analiza usług bez konieczności ponownego uruchamiania systemu |
| -f | Uwzględnij procesy potomne | Pełne zarejestrowanie pracowników i pojawień się |
| -c | Zestawienie statystyczne | Częstotliwość i czas trwania poszczególnych połączeń |
| -tt / -T | Bardziej szczegółowe informacje dotyczące czasu | Rozpoznawanie przedziałów czasowych i czasów trwania |
| -o PLIK | Przekierowanie wydruku | Umożliwić późniejszą analizę |
| -ff | Zapisywanie na plik procesowy | Oddzielić rodziców od dzieci |
| -s N | Zwiększyć długość argumentu | Uwidocznianie odciętych ścieżek |
Bezpieczeństwo, prawa i skutki uboczne
Zawsze obliczam Nad głową ponieważ strace przechwytuje każde wywołanie i rejestruje, co czasowe Efekty może spowodować. W przypadku środowisk produkcyjnych o ograniczonych zasobach przeprowadzam więc śledzenie w sposób ukierunkowany i zwięzły. W zależności od systemu mogą zadziałać mechanizmy bezpieczeństwa, takie jak ptrace_scope lub zasady SELinux, które ograniczają dostęp – co sprawdzam z wyprzedzeniem. Jeśli analizuję procesy przetwarzające dane wrażliwe, dbam o to, by wyniki były zredagowane, lub przeprowadzam analizę w izolowanym środowisku. W ten sposób zachowuję poufność, ograniczam obciążenie do umiarkowanego poziomu, a mimo to uzyskuję szybkie wyniki.
Praktyczne przykłady z życia codziennego
Usługa internetowa uruchamia się, ale zwraca błąd 500: Za pomocą -e trace=plik szybko odnajduję to, czego brakuje Konfiguracja-File, ponieważ funkcja openat zwraca błąd ENOENT. Narzędzie CLI natychmiast się zawiesza: widzę błąd EACCES w bibliotece i odpowiednio dostosowuję uprawnienia. Aplikacja działa wolno: opcja -c pokazuje wiele drobnych wywołań read, zwiększam buforowanie i ograniczam natężenie wywołań systemowych. Proces roboczy zawiesza się: futex pozostaje w stanie zablokowanym, sprawdzam blokady w kodzie i usuwam blokadę. Występuje limit czasu DNS: przerwy między wywołaniami `sendto` i `recvfrom` wskazują na problem sieciowy poza aplikacją.
Uwidocznienie treści danych i kontekstu deskryptorów
Jeśli same wartości zwracane mi nie wystarczają, wyłączam wyświetlanie określonych elementów bufor danych oraz kontekst dotyczący Deklaratory plików . Z -s N zwiększam widoczną długość ciągu znaków dla argumentów (np. 256 lub 1024 znaki), aby wyświetlić pełne ścieżki, bloki JSON lub nagłówki. W przypadku treści niedrukowalnych używam -x (znaki spoza zestawu ASCII w postaci szesnastkowej) lub -xx (wszystko w formacie szesnastkowym), co jest szczególnie pomocne w przypadku protokołów binarnych. Z -e read=all oraz -e write=all wyświetlam rzeczywiste dane użytkowe z wywołań funkcji read()/write() i w ten sposób sprawdzam, czy żądania/odpowiedzi wydają się wiarygodne. Równolegle chętnie aktywuję -y, aby strace wyświetlał wraz z deskryptorami plików odpowiadające im ścieżki (np. 3), oraz -yy w celu uzyskania dodatkowych szczegółów dotyczących obiektów typu Socket. Korzystam z tej głębokości z umiarem, ponieważ szybko generuje ona dużą ilość danych wyjściowych i może zawierać dane wrażliwe – dlatego w środowiskach produkcyjnych wybieram wąski dekolt i regularnie zmieniaj pliki.
Bardziej szczegółowe filtry: wywołania systemowe, ścieżki i wykluczenia
Aby zachować koncentrację, oprócz gotowych kategorii korzystam również z filtry o drobnym uziarnieniu. Ograniczam się do -e trace=openat,statx,access wprowadzić dokładnie te wywołania systemowe, które mnie obecnie interesują, albo nadal korzystać z kategorii takich jak -e trace=signal lub -e trace=ipc wracam do tego, gdy chcę mieć na oku sygnały lub komunikację międzyprocesową. Praktyczne jest również -P ŚCIEŻKA, aby ograniczyć dostęp tylko do jednego lub kilku konkretne ścieżki na przykład -P /etc,/var/www. Jeśli taki evergreen jak futex jeśli mi to przeszkadza, po prostu odwracam zasadę filtrowania i wykluczam go, podając wyraźnie tylko te wywołania, które są istotne. W ten sposób otrzymuję o niskim poziomie szumu Skup się na obszarze błędu, jednocześnie ograniczając obciążenie systemowe.
Rzetelne rejestrowanie osi czasu, śladów stosu i krótkotrwałych procesów
Czas jest moim kompasem. Oprócz -tt Aby uzyskać precyzyjne znaczniki czasu, chętnie korzystam z -ttt, gdy chcę porównać przebiegi na wielu hostach, ponieważ znaczniki czasu epoki ułatwiają analizę. -r pokazuje mi względne odległości od momentu startu, co ułatwia wykrywanie Kąciki wypoczynkowe w skrócie. W przypadku sporadycznych awarii pomaga mi -i (wskaźnik instrukcji) wraz z -k (stack trace), aby sprawdzić, z jakiego kontekstu stosu pochodzi kosztowne lub błędne wywołanie – szczególnie przydatne, gdy dostępne są informacje dotyczące debugowania. W przypadku bardzo krótkotrwałe Programy lub zadania cron uruchamiam bezpośrednio pod strace lub korzystam z -ff -o, żeby nie przeoczyć żadnego wczesnego wywołania `execve` ani żadnej inicjalizacji. Jeśli chcę porównać kilka przebiegów, sortuję statystyki -c za pomocą -S time, aby szybciej wykrywać skoki w całkowitym czasie trwania.
Thready, rozgałęzienia i złożone drzewa usług pod kontrolą
Jak tylko kilka procesów lub wątków które są zaangażowane, włączam -f , aby uruchomić procesy potomne, a następnie zapewniam sobie za pomocą -ff oddzielne pliki wyjściowe dla każdego PID. Dzięki temu mogę później przeanalizować osobny wątek dla każdego pracownika i uniknąć pomyłek. W środowiskach z wieloma krótkotrwałymi procesami potomnymi pomaga mi również połączenie -e trace=process (execve/clone/fork/exit) oraz Dane dotyczące czasu, aby zrozumieć powstawanie i ustanie procesów w miarę upływu czasu. Powtarzające się wzorce, takie jak „proces nadrzędny czeka na proces podrzędny“, rozpoznawalne po wait4 oraz brak aktywności ze strony dziecka wskazują na blokady lub niedobór zasobów. Kiedy zajmuję się migracjami, porównuję drzewa usług na starym i nowym serwerze i dzięki temu sprawdzam, czy Rozkład pracowników lub Preforking przebiega identycznie lub nieznacznie się różni.
Kontenery, przestrzenie nazw i uprawnienia w codziennej praktyce
W kontenerze lub Przestrzeń nazw-W scenariuszach tych planuję uprawnienia z wyprzedzeniem. Aby podłączyć się do obcych procesów, potrzebuję odpowiednich uprawnień lub możliwości (np. CAP_SYS_PTRACE) oraz mechanizmów bezpieczeństwa, takich jak ptrace_scope lub zasady mogą blokować dostęp. Jeśli programy Ziel i Tracer działają w różne przestrzenie nazw, albo dołączam się do tej samej przestrzeni nazw, albo celowo przechodzę do kontekstu docelowego. W środowiskach orkiestrowanych biorę również pod uwagę, że identyfikatory PID są krótkotrwałe i Obracanie śladów muszę to zrobić, aby nie stracić istotnego okresu. Ograniczam ilość wysyłanych danych (np. nie przesyłam pełnych ładunków), gdy przez łącze przepływają dane wrażliwe, i ściśle ograniczam czas działania do Faza problemowa, aby zminimalizować skutki uboczne.
Strace w procesach kompilacji i wydawania
Ja też korzystam ze strace wczesny w ramach CI/CD w celu sprawdzenia poprawności pakietów, ścieżek i uprawnień. Przebieg testowy z -e trace=plik szybko pozwala sprawdzić, czy plik binarny z kontenera kompilacji znajdzie później w systemie docelowym te same biblioteki i ścieżki konfiguracyjne. W przypadku testów regresyjnych zapisuję sobie Linia bazowa: Krótkie uruchomienie z opcją -c i spójnymi opcjami (np. -ttt, -S time) służy jako punkt odniesienia. W kolejnych sekwencjach porównuję statystyki, aby wykryć nagłe skoki w statx, read lub Połączyć szybko je rozpoznać. Aby artefakty pozostały zwięzłe, skupiam się na konkretnych śladach, nadaję plikom nazwy w sposób deterministyczny (w tym identyfikatory kompilacji lub commitów) oraz w razie potrzeby normalizuję identyfikatory procesów (PID) lub sygnatury czasowe podczas generowania różnic tekstowych.
Typowe przeszkody i schematy interpretacyjne
Na pewne cechy zwracam uwagę rutynowo. W przypadku przerwanych wywołań często pojawia się EINTR (przerwane sygnałami) – pojedyncze wystąpienie nie budzi obaw, ale ciąg takich zdarzeń jest podejrzany. Czy widzę ERESTARTSYS- podobne komunikaty wskazują na wywołania systemowe ponownie uruchomione przez jądro; sprawdzam źródła sygnałów i maski. Jeśli na wyjściu pojawiają się komunikaty z różnych procesów zmieszane je rozdzielam ściśle za pomocą -ff, a do połączenia wykorzystuję sygnatury czasowe. Ślady bez rozpoznawalnych errno-Błędy, ale występujące w dużych odstępach czasu, budzą moje podejrzenia co do opóźnień we/wy lub sieciowych – wtedy skupiam się na operacjach read/write/connect i uzupełniam pomiary czasu. Pozostają ścieżki odcięty, zwiększam wartość -s lub wyłączam skróty, wybierając tryb szczegółowego wyświetlania. Jeśli pojawią się różnice między plikami binarnymi 32-bitowymi a 64-bitowymi (np. otwórz vs. openat), zwracam uwagę na architekturę i w razie wątpliwości testuję oba warianty.
Selekcjonowanie konkretnych treści: czytelność przed zalewem danych
Właśnie w sytuacjach stresowych staram się zachować umiar: precyzyjnie definiuję Pytania badawcze (Brak pliku? Awaria sieci? Przerwanie drzewa procesów?), następnie ustaw minimalnie niezbędne filtry i zakończ śledzenie natychmiast po Dowód. W przypadku zmian w zespole piszę krótkie Uwagi towarzyszące w opisie zgłoszenia: odpowiednie wywołanie, parametry, errno, kontekst czasowy oraz przypuszczalną przyczynę. Podczas długich sesji nie ustawiałem wszystkich opcji naraz, lecz włączałem je krok po kroku W kolejności: najpierw -e trace=…, potem -tt/-T, następnie -y/-s, a w razie potrzeby -x/-xx. Taka sekwencja zapobiega zalaniu mnie danymi i przyspiesza wyciągnięcie właściwych wniosków. Jeśli liczy się wydajność, przed wykonaniem pełnych śladów preferuję opcję -c (wraz z -S time) oraz wąski wybór wywołań.
Kompaktowe podsumowanie
Z strace szybciej wykrywam źródła błędów, ponieważ mam prawdziwe Wywołania systemowe zamiast zwykłych wpisów w logach. Filtry, sygnatury czasowe i statystyki -c dostarczają mi jasnych wskazówek dotyczących ścieżek, uprawnień, sieci i czasów oczekiwania. Uruchamiam programy bezpośrednio pod strace lub na chwilę podłączam się do uruchomionych procesów (PID), skupiam się na wynikach i zatrzymuję, gdy tylko pojawi się błąd. W celu późniejszej analizy zapisuję pliki za pomocą opcji -o i -ff, w razie potrzeby zwiększam wartość -s i porównuję przebiegi między hostami, aby wykryć różnice. W ten sposób rozwiązuję codzienne problemy na serwerach z systemem Linux w ciągu minut, a nie godzin.
