...
logo hostingu

BPFtrace w hostingu: szybsze wykrywanie problemów z serwerem

Pokażę, w jaki sposób narzędzie bpftrace w środowiskach Linux znacznie skraca czas potrzebny na zlokalizowanie przyczyny błędu, a przy tym Jądro-umożliwia wykorzystanie sygnałów. Zamiast zgadywać, mierzę wywołania systemowe, opóźnienia wejścia/wyjścia oraz zdarzenia sieciowe na żywo w eBPF-kontekst – bez zatrzymywania usług.

Punkty centralne

Poniższe punkty dają szybki przegląd głównych zagadnień poruszonych w niniejszym artykule.

  • Dogłębny wgląd w wywołaniach systemowych, operacjach wejścia/wyjścia i sieci bezpośrednio z jądra
  • Niskie obciążenie systemowe dzięki bezpiecznym programom eBPF w jądrze systemu
  • Szybkie zawężenie zakresu poszukiwań związane z wąskimi gardłami procesowymi, wejścia/wyjścia i baz danych
  • Elastyczne śledzenie z filtrami, histogramami i śladami stosu
  • Przebieg pracy w gabinecie w przypadku nagłych zdarzeń – w ciągu kilku minut

Dlaczego bpftrace pozwala szybciej wykrywać problemy w hostingu

W nowoczesnych środowiskach hostingowych wiele usług konkuruje o Zasoby, podczas gdy klasyczne pulpity nawigacyjne często pokazują jedynie wartości powierzchniowe. Ja schodzę o poziom niżej: bpftrace śledzi wywołania systemowe, punkty śledzenia i haki funkcyjne, pokazując mi, co naprawdę spowalnia system. Przekroczenia limitów czasu przy niepozornym obciążeniu procesora często wskazują na opóźnienia we/wy lub wywołania blokujące. Właśnie w tym zakresie bpftrace wyróżnia się dzięki zliczeniom, histogramom opóźnień i śladom stosu pochodzącym bezpośrednio z Jądro. W ten sposób przypisuję źródła obciążenia do konkretnych procesów, kontenerów lub zapytań i podejmuję ukierunkowane działania.

Jak współdziałają eBPF i bpftrace

eBPF uruchamia małe, sprawdzone programy w Jądro i dostarcza zdarzenia z pierwszej ręki. bpftrace kompiluje skrypty w czasie wykonywania do kodu bajtowego eBPF i dołącza je do sond, filtrów i akcji. Wybieram na przykład punkt śledzenia dla odczytów plików, filtruję według nazwy procesu i agreguję opóźnienia w histogramie. Schemat „sonda – filtr – akcja“ pozostaje przejrzysty, nawet gdy mierzę jednocześnie kilka sygnałów. W ten sposób w ciągu kilku minut tworzę obserwację, która dostarcza mi kluczowych Wskaźniki materiały eksploatacyjne.

Krótkie, zwięzłe powiedzonka na wypadek sytuacji kryzysowej

W takich sytuacjach liczy się szybkość. Używam zwięzłych, jednozdaniowych sformułowań, które w ciągu kilku sekund wskazują na pewien wzorzec. Oto kilka moich sprawdzonych przykładów na początek:

# Zliczanie „głośnych“ operacji na plikach według nazwy procesu (czyścenie co 5 s)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }'

Histogram opóźnień # dla odczytów plików (na proces)
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
  @lat[comm] = hist(nsecs - @ts[tid]);
  delete(@ts[tid]);
}'

# Grupowanie retransmisji TCP za pomocą stosów jądra
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'

# Zsumowanie czasów SoftIRQ (okno 10 s)
bpftrace -e '
tracepoint:irq:softirq_entry { @t[args->vec] = nsecs; }
tracepoint:irq:softirq_exit /@t[args->vec]/ {
  @soft[args->vec] = sum(nsecs - @t[args->vec]);
  delete(@t[args->vec]);
}
interval:s:10 { print(@soft); clear(@soft); }'

# – wyświetlenie obciążenia funkcji accept() na serwerze bazy danych lub serwerze WWW
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'

Dzięki tym „sondom“ szybko sprawdzam, czy jakaś usługa otwiera nienormalnie dużą liczbę plików, czy operacje wejścia/wyjścia są spowolnione, czy też sieć się zawiesza. Następnie doprecyzowuję filtry do PID, nazwy procesów lub ścieżki.

Diagnoza procesów i zasobów na serwerach produkcyjnych

Jeśli pojedyncze konto lub kontener spowalnia serwer współdzielony, zliczam wywołania systemowe na Proces i wykrywam „głośne“ źródła problemów. Niezwykle duża liczba wywołań funkcji `execve` wskazuje na nadmierne uruchamianie procesów, co może świadczyć na przykład o błędnych zadaniach cron. Jeśli jakaś usługa otwiera niezliczoną liczbę plików, od razu to dostrzegam i za pomocą filtrów ograniczam sprawdzanie do określonych ścieżek. W przypadku intensywnie obciążonych serwerów WWW jest to na wagę złota, ponieważ pozwala mi szybko wyodrębnić źródła zakłóceń. Kto chce zagłębić się w pomysły dotyczące narzędzi, powinien dodatkowo zapoznać się z podejściami do narzędzia analityczne eBPF i stosuje tę zasadę do własnych hostów.

Widok kontenerów i Kubernetes z wykorzystaniem cgroups

W środowiskach wielodostępnych lub na hostach Kubernetes potrzebuję wyraźnego oddzielenia klientów. bpftrace oferuje mi w tym celu cgroup-Perspektywa jako klucz:

# Grupowanie wywołań systemowych według cgroup (kontener) i nazwy procesu
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'

W ten sposób mogę sprawdzić, który kontener generuje hałas, bez konieczności ręcznego zbierania poszczególnych identyfikatorów PID. W celu przeprowadzenia szczegółowej analizy stosuję dodatkowe filtry:

# Uwzględnij tylko PHP-FPM (np. w kontenerze aplikacji)
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'

W Kubernetes często mierzę w Węzeł i pogrupuj według cgroup. Przyporządkowanie identyfikatorów cgroup do nazw podów/kontenerów dokumentuję w moim runbooku (kubectl/CRI), aby móc jednoznacznie odnosić się do wyników pomiarów.

Niezawodny pomiar opóźnień we/wy i systemu plików

Powolne ładowanie stron pomimo „całkiem niezłego“ procesora często wskazuje na I/O-wykrywam wąskie gardła. Mierzę operacje odczytu i zapisu dla każdego procesu, rejestruję powolne ścieżki i tworzę histogramy opóźnień. W środowiskach WordPressa pozwala mi to ustalić, czy przepustowość ograniczają liczne małe pliki PHP, czy też duże pliki multimedialne. Następnie decyduję, czy w pierwszej kolejności zastosować buforowanie, pamięć podręczną kodu operacyjnego PHP (PHP Opcode Cache) czy też optymalizację systemu plików. Osoby pragnące zgłębić ten temat znajdą dodatkowe informacje na temat Opóźnienia dyskowe w systemie pamięci masowej i może precyzyjnie dostosowywać punkty pomiarowe.

Wyświetlanie czasów oczekiwania poza procesorem i na blokadę

Nie każdy czas oczekiwania to operacja wejścia/wyjścia: wątki mogą poza procesorem blokować – na przykład na zamkach. Wykorzystuję do tego zdarzenia Futex i Scheduler.

# Czasy oczekiwania na futex (konflikty blokad) w postaci histogramu
bpftrace -e '
tracepoint:syscalls:sys_enter_futex { @ts[tid] = nsecs; }
tracepoint:syscalls:sys_exit_futex /@ts[tid]/ {
  @futex[comm] = hist(nsecs - @ts[tid]);
  delete(@ts[tid]);
}'

Dzięki takim profilom widzę, czy procesy robocze PHP-FPM lub wątki bazy danych czekają na blokady. W połączeniu z historiami operacji wejścia/wyjścia odłączam Przechowywanie- z Współbieżność-Problemy.

Wyświetlanie błędów sieciowych, SoftIRQ i retransmisji

Skargi dotyczące sporadycznych przekroczeń limitu czasu często przypisuję Sieć-sygnały. Monitoruję retransmisje TCP, zdarzenia RST i przerwania połączeń bezpośrednio w jądrze. Dodatkowo sprawdzam SoftIRQ, ponieważ przeciążone kolejki sieciowe pozostawiają tam ślady. Wzorzec składający się z retransmisji oraz rosnących czasów softIRQ wskazuje na utratę pakietów, zatory w buforach lub problemy z QoS. Dobrym uzupełnieniem w procesie ustalania przyczyn są artykuły w tle dotyczące SoftIRQ i przepustowość sieci, które łączę z pomiarami za pomocą bpftrace.

Przykład: hosting WordPress z sporadycznymi błędami 504 (przekroczenie limitu czasu)

Serwer współdzielony zgłasza błąd 504, a obciążenie procesora wynosi zaledwie 35%. Moja procedura:

  • Hipoteza „sieć lub wejścia/wyjścia“. Uruchamiam retransmisje i pomiar czasu SoftIRQ. Wynik: niewiele retransmisji, SoftIRQ stabilne.
  • Przejście na I/O: wykres opóźnień vfs_read pokazuje długi ogon sięgający 80 ms dla php-fpm. Duża liczba wywołań funkcji openat na żądanie.
  • Filtr na ścieżki w katalogach wp-content i wp-includes: dominują niezliczone drobne operacje odczytu plików.
  • Kontrola krzyżowa blokad: Futex-Histo bez nieprawidłowości – brak kolizji blokad.
  • Działanie: Dostosować konfigurację OPCache, aby bardziej intensywnie buforować zasoby statyczne. W rezultacie zmniejszy się liczba operacji „openat” oraz opóźnienia.

Po niecałych 15 minutach aktywnego śledzenia staje się jasne: przyczyną nie jest sieć, lecz Operacje wejścia/wyjścia na plikach i brak buforowania powodują przekroczenie limitu czasu.

Bazy danych i PHP-FPM: szybkie lokalizowanie wąskich gardeł

W przypadku MySQL/MariaDB analizuję wywołania systemowe, blokady i opóźnienia we/wy w Procesy DB . Śledzę fazy accept/connect, aby sprawdzić, czy połączenia się zaciągają lub czy utknęły procesy uzgadniania TLS. W przypadku PHP-FPM sprawdzam, czy liczba wywołań execve i operacji na plikach jest nietypowo wysoka, co może wskazywać na brak buforowania. Dzięki śladom stosu (stacktraces) dla określonych wywołań systemowych rozpoznaję, w którym miejscu kodu oczekują żądania. W ten sposób stopniowo wykluczam sieć, aplikację i bazę danych, aż znajdę najwęższe Miejsce.

Najlepsze praktyki dotyczące wydajnych serwerów

Każde śledzenie rozpoczynam od jasnego Pytanie badawcze oraz zawężam zakres sond za pomocą filtrów. Ograniczenia czasowe lub interwały pozwalają utrzymać ilość danych na rozsądnym poziomie. W przypadku powtarzających się analiz zapisuję skrypty z sensownymi filtrami domyślnymi, takimi jak PID, cgroup lub nazwy procesów. Przed wdrożeniem na serwerach klientów testuję skomplikowane skrypty na systemach stagingowych. Dzięki temu obciążenie pozostaje niewielkie, a ja zapobiegam niepotrzebnym Efekty uboczne.

Jakość pomiarów, obciążenie ogólne i limity w praktyce

bpftrace, przy zastosowaniu ukierunkowanych sond, generuje obciążenie procesora rzędu jednocyfrowego procentu, o ile przestrzegam następujących zasad:

  • Filtrowanie na wlocie: Filtruję na wczesnym etapie (np. według comm/PID), zamiast najpierw sortować w Maps.
  • Pobieranie próbek: W przypadku bardzo gorących próbek stosuję próbkowanie, np. 1% zdarzeń: 
    tracepoint:syscalls:sys_enter_openat
/ rand() % 100 == 0 / { @[comm] = count(); }
  • Oszczędne stosowanie śladów stosu: kstack/ustack tylko w razie potrzeby – najpierw policzyć, potem pogłębić wiedzę.
  • Rozmiar bufora: W przypadku szczytowego obciążenia podczas wydarzeń zwiększam rozmiar bufora pierścieniowego: 
    export BPFTRACE_PERF_RB_PAGES=4096
  • Trzymaj okno otwarte przez chwilę: Odstępy (5–30 s) i wyraźne zakończenie zapobiegają chaosowi w danych.

Jeśli zauważę „dropped events“, zwiększam bufor, zmniejszam głębokość stosu lub zaostrzam filtry. Aby zapewnić dokładność, preferuję Punkty śledzenia (stabilna wersja ABI) w porównaniu z kprobes (nazwy funkcji jądra mogą się różnić).

Bezpieczeństwo, zarządzanie i zasady wielodostępności

W przypadku hostingu współdzielonego zwracam szczególną uwagę na Ochrona danych oraz jasno określone zakresy. Śledzę sygnały techniczne, a nie dane klientów, i dokumentuję powód, zakres oraz czas trwania. W przypadku środowisk wielodostępnych ustalam sztywne wytyczne: kto może uruchomić śledzenie, jakie filtry są konieczne i kiedy kończę śledzenie. Logi zawierające wrażliwe ścieżki minimalizuję lub pseudonimizuję. W ten sposób uzyskuję przydatne dane techniczne bez naruszania granic dzierżawców i zachowuję Zgodność w.

Instalacja i wymagania na nowoczesnych serwerach z systemem Linux

W przypadku bpftrace korzystam z systemu Linux 5.x, ponieważ funkcje i Stabilność są tam zauważalnie lepsze, nawet jeśli za dolną granicę uznaje się wersję 4.9. Instaluję bpftrace za pomocą apt lub dnf i uzupełniam nagłówki jądra, gdy tylko pojawią się potrzeby zastosowania bardziej złożonych sond. Następnie sprawdzam konfiguracje cgroup, środowiska uruchomieniowe kontenerów oraz moduły bezpieczeństwa, które regulują dostęp do sond. Krótki test z prostymi punktami śledzenia pozwala upewnić się, że sygnatury i symbole są zgodne. Dzięki temu nic nie stoi na przeszkodzie uporządkowanemu uruchomieniu i mogę przeprowadzić pierwsze Pomiary jechać.

Przenośność: BTF, rozdzielczość symboli i stabilne sondy

Jeśli chodzi o solidne skrypty, stawiam na BTF- informacje o typach (vmlinux), które pomagają bpftrace w rozpoznawaniu pól. Jeśli ich brakuje, wolę korzystać z punktów śledzenia zamiast kprobes. Dla uprobes (W środowisku użytkownika) potrzebuję nieokrojonych plików binarnych lub oddzielnych symboli debugowania – opłaca się to zwłaszcza w przypadku PHP-FPM lub mysqld. Sprawdzam wersje za pomocą polecenia „bpftrace –info“ i w skryptach uwzględniam niewielki blok kompatybilności na wypadek, gdyby nazwy zdarzeń różniły się w zależności od jądra.

Przebieg pracy w gabinecie: od objawu do przyczyny w 15 minut

Najpierw sformułuję Hipoteza: Sieć, wejścia/wyjścia, procesor czy baza danych? W takim razie uruchamiam po jednym szybkim śledzeniu na najbardziej prawdopodobnym poziomie, na przykład w zakresie retransmisji lub opóźnień związanych z plikami. Jeśli pierwsze minuty wskazują na pewien wzorzec, doprecyzowuję filtry, dołączam do nich ślady stosu i ograniczam czas działania. Jeśli podejrzenia się potwierdzą, przeprowadzam pomiary głębiej w danej usłudze i rejestruję już tylko istotne ścieżki. Dzięki temu zakresowi unikam działania na ślepo i szybko dochodzę do najwęższej Przyczyna.

Podręcznik postępowania: 15-minutowa akcja ratunkowa

  • Minuta 0–2: Wybierz hipotezę (sieć/we/wy/procesor/baza danych). Uruchom skrypt Baseline-One-Liner.
  • Minuta 3–5: Zidentyfikować pierwsze odstępstwa (np. wysoka liczba openatów, retransmisje, histogramy Futex).
  • Minuta 6–8: Poprawić filtry (comm/PID/cgroup, ścieżki) i dodać histogramy opóźnień.
  • Minuta 9–12: Włącz ślady stosu tylko w punkcie newralgicznym, aby uwidocznić fragmenty kodu.
  • Minuta 13–15: Wybrać odpowiednie działanie (buforowanie, limity, zmiana konfiguracji) i krótko je przetestować.

Tabela porównawcza: Probes i ich zastosowanie w życiu codziennym

Poniższa tabela przedstawia typowe Próbki, ich zakres zastosowania oraz główne zalety w kontekście hostingu. Korzystam z nich jako ściągawki, gdy chcę szybko wybrać odpowiedni punkt pomiarowy.

Typ próbki Użycie Przykład Korzyści
tracepoint:wywołania systemowe Zliczanie/filtrowanie wywołań systemowych sys_enter_openat, execve „Głośne“ Procesy Znajdź
kprobe/kretprobe Pomiar funkcji jądra vfs_read, tcp_retransmit Wejścia/wyjścia i zasilanieOpóźnienia widoczny
uprobes/uretprobes Śledzenie funkcji w przestrzeni użytkownika Ikony mysqld, php-fpm Lokalizowanie hotspotów DB/aplikacji
tracepoint:net/* Rozpoznawanie wydarzeń sieciowych Ponowne transmisje TCP, RST Limit czasu—Przyczyny ograniczyć
perf events Perspektywa procesora i harmonogramu Profile on-cpu/off-cpu Wykrywanie wąskich gardeł w planowaniu

Podsumowanie dla administratorów i specjalistów DevOps

bpftrace wyświetla mi ostry Soczewka na sygnały jądra i aplikacji, które często umykają uwadze w ramach klasycznego monitorowania. Zaczynam od niewielkiego zakresu, stosuję ukierunkowane filtrowanie i kontroluję czasy działania, aby wyniki pomiarów pozostały przejrzyste. Za pomocą zaledwie kilku wierszy skryptu wykrywam szum procesów, opóźnienia w obsłudze plików, retransmisje sieciowe oraz czasy oczekiwania na bazę danych. Takie podejście zauważalnie skraca średni czas rozwiązania problemu (Mean Time to Resolution) na hostach produkcyjnych. Kto włączy bpftrace do swojego przepływu pracy, ten skutecznie rozwiązuje incydenty hostingowe i zapewnia zauważalną poprawę działania stron internetowych oraz interfejsów API. responsywny.

Artykuły bieżące