bpftool – wprowadzenie do nowoczesnej analizy jądra systemu za pomocą eBPF

Pokażę ci, jak pracować z bpftool możesz celowo analizować działające systemy Linux, sterować programami eBPF i uzyskiwać przy tym miarodajne dane telemetryczne bez konieczności ponownej kompilacji jądra. Artykuł ten krok po kroku przeprowadzi Cię przez proces instalacji, omówi podstawowe koncepcje, typowe zastosowania oraz przydatne procedury, dzięki czemu będziesz mógł Analiza jądra wykorzystuje je bezpiecznie w eksploatacji i podczas prac rozwojowych.

Punkty centralne

Na początek podsumuję najważniejsze kwestie, abyś mógł właściwie zorientować się w kolejnych rozdziałach i Priorytety możesz ustawić.

• bliskość jądra: Bezpośredni dostęp do programów eBPF, map i statystyk
• Przejrzystość: Logi weryfikatora, kod bajtowy i zrzuty JIT do celów debugowania
• gotowość do produkcji: dane wyjściowe w formacie JSON, możliwość tworzenia skryptów, powtarzalne procesy
• Szerokość: Sieć, wywołania systemowe, harmonogram, cgroups, perf_events
• Ekosystem: Uzupełnia zaawansowane narzędzia, takie jak BCC i bpftrace

Wykorzystuję wymienione punkty, aby przedstawić praktyczne kroki oraz Decyzje ułatwić. Dzięki temu szybko zorientujesz się, w jakich sytuacjach bpftool przynosi bezpośrednie korzyści, a w jakich lepiej sprawdzają się inne narzędzia. Lista ta służy jako przewodnik po przykładach przedstawionych w kolejnych rozdziałach i skupia się na Mierzalność. Podczas czytania miej na uwadze swój system docelowy, ponieważ opcje zależą od konfiguracji i wersji jądra. Im jaśniej sformułujesz swój cel, tym szybciej eBPF i bpftool dostarczą wyniki Sygnał zamiast szumu.

eBPF jako bezpieczne środowisko uruchomieniowe w jądrze

eBPF zapewnia bezpieczne środowisko uruchomieniowe w Jądro który powiązuje małe programy z określonymi zdarzeniami i przed ich uruchomieniem poddaje je rygorystycznej kontroli. Weryfikator zapobiega niedozwolonym dostępom do pamięci i pętlom, dzięki czemu systemy pozostają pod kontrolą i zdolny do działania. Podłączam programy do Kprobes, Tracepoints, XDP lub cgroups i uzyskuję precyzyjne dane kontekstowe. Ta bliskość zapewnia wartości pomiarowe bez kosztownych przejść przez wywołania systemowe i bez konieczności tworzenia modułów. W ten sposób powstaje elastyczna warstwa telemetryczna, którą wykorzystuję wraz z bpftool uczynić je widocznymi, sprawdzalnymi i kontrolowalnymi.

Instalacja i wymagania

Najpierw sprawdzam wersję jądra i jego funkcje, ponieważ wiele funkcji zaczyna działać dopiero od 5.x w całości. W dystrybucjach instaluję bpftool jako pakiet lub kompiluję go ze źródeł jądra w katalogu tools/bpf/bpftool, w zależności od stanu utrzymania systemu. Do kompilacji potrzebuję Clang/LLVM, libelf, make oraz odpowiednich plików nagłówkowych, aby łańcuch narzędzi był zgodny z jądrem pasuje. Po instalacji sprawdzam za pomocą polecenia “bpftool version”, czy funkcja jest dostępna, i porównuję ją z moimi wymaganiami. Jeśli możliwości jądra są zgodne, uruchamiam testy na oddzielnym systemie, zanim przejdę do hostów produkcyjnych następować.

bpffs i przypinanie: przegląd cyklu życia obiektu

Aby zapewnić powtarzalność procesów, najpierw montuję system plików BPF w katalogu “/sys/fs/bpf”. Jeśli go nie ma, tworzę go za pomocą polecenia “mount -t bpf bpf /sys/fs/bpf” i sprawdzam przestrzenie nazw, jeśli w grę wchodzą kontenery. Następnie przypinam załadowane obiekty do stałych ścieżek, na przykład “bpftool prog pin id X /sys/fs/bpf/myapp/xdp_ingress” lub “bpftool map pin id M /sys/fs/bpf/myapp/counters”. W ten sposób programy, linki i mapy przetrwają ponowne uruchomienie procesu, pozostają wykrywalne i są jednoznaczne. adresowalny.

Organizuję hierarchię pinningową według usługi, haka i wersji, na przykład “/sys/fs/bpf/”służba/hook/wersja”. Ułatwia to przywracanie poprzednich wersji i testy równoległe. W przypadku załączników preferuję podejście oparte na linkach: “bpftool link list” pokazuje mi stabilne identyfikatory, a “bpftool link pin id L /sys/fs/bpf/myapp/link_xdp” utrwala połączenie. Podczas porządkowania najpierw usuwam piny (rm), a dopiero potem obiekty są zwalniane. W ten sposób unikam Sieroty-programy, które działają w tle, pozostając niezauważone.

Główne podkomendy i koncepcje

bpftool grupuje polecenia według typów obiektów, takich jak prog, map, cgroup lub feature, co pozwala na logiczny podział procesów roboczych. Korzystam z poleceń “prog list” i “prog show”, aby uzyskać ogólny przegląd, “dump xlated/jited” w celu uzyskania szczegółowych informacji oraz “map dump/lookup” do analizy przepływu danych. Podpolecenie “feature” wyświetla aktywne typy pomocników i map, co pozwala uniknąć późniejszych błędów. Wyniki w formacie JSON ułatwiają automatyzację w ramach CI/CD oraz zarządzanie konfiguracją. Poniższa tabela zawiera podsumowanie typowych zadań i przykładów kompaktowy razem.

Obiekt	Zadanie	Przykład
prog	Wymienić i opisać programy	bpftool prog list | bpftool prog show id X
prog	Wyświetl kod bajtowy/JIT	bpftool prog dump xlated id X | dump jited id X
prog	Pobieranie i załączanie	bpftool prog load file.o /sys/fs/bpf/p && … attach
mapa	Sprawdź treści i klucze	bpftool map dump id M | map lookup id M key HEX
funkcja	Wyświetl możliwości jądra	bpftool – funkcja probe

BTF, CO-RE i szkielety w życiu codziennym

Dbam o to, by BTF było dostępne w jądrze, ponieważ umożliwia to korzystanie z CO-RE (Compile Once – Run Everywhere) oraz wygodne wyświetlanie wyników debugowania. Za pomocą polecenia “bpftool feature probe” sprawdzam, czy BTF jest aktywne, a w razie potrzeby przeglądam informacje o typach za pomocą polecenia “bpftool btf dump file /sys/kernel/btf/vmlinux”. Na potrzeby programowania generuję odpowiedni plik nagłówkowy na podstawie typów jądra za pomocą polecenia “bpftool gen vmlinux”, co pozwala mi bezpiecznie odwoływać się do struktur. Znacznie ogranicza to liczbę punktów awarii podczas aktualizacji jądra.

W zakresie pakietowania stawiam na szkielety: polecenie “bpftool gen skeleton obj.o” generuje opakowanie w języku C, które hermetyzuje operacje ładowania, dołączania, dostępu do map oraz czyszczenia. Dzięki temu zmniejsza się ilość mojego kodu łączącego, a interakcja między przestrzenią użytkownika a programem eBPF pozostaje solidny. CO-RE pozwala mi korzystać z tych samych artefaktów w różnych jądrach, o ile dostępne są funkcje pomocnicze i haki – sprawdzam to na wczesnym etapie za pomocą polecenia “feature probe”.

Analiza wydajności za pomocą narzędzia bpftool

W przypadku pytań dotyczących wydajności korzystam z narzędzia bpftool do obliczania wywołania poszczególnych programów, mierzę czasy wykonania i porównuję je ze szczytami obciążenia. W ten sposób rozpoznaję, które ślady (traces) działają bardzo intensywnie lub czy filtr XDP na „gorących” ścieżkach zajmuje zbyt dużo mocy procesora. Następnie oceniam, czy bardziej sensowne jest stosowanie próbkowania, czy też węższych filtrów. W przypadku anomalii analizuję zrzuty JIT, aby zrozumieć ścieżki kodu i uniknąć zbędnych instrukcji. Na koniec dane liczbowe trafiają do pulpitów nawigacyjnych, aby operatorzy mogli na stałe Przejrzystość zachować.

Wartości liczbowe, mapy na procesor oraz statystyki

Analizuję wynik polecenia “bpftool prog show id X”, aby sprawdzić wartości “run_time_ns” i “run_cnt”. Ich stosunek wskazuje mi średnie czasy wykonania, a wartości odstające interpretuję na podstawie wskaźników obciążenia. W przypadku liczników map zwracam uwagę na warianty na procesor: niektóre zrzuty pokazują wartości na procesor, inne są zagregowane. Do dokładnych analiz korzystam z wyników w formacie maszynowym i celowo obliczam agregacje, aby szczyty na poszczególnych procesorach nie zatonąć.

Aby szybko zapoznać się z wynikami śledzenia, uruchamiam polecenie “bpftool prog tracelog”. Dzięki temu odczytuję wyniki wydruku z bufora śledzenia bez konieczności korzystania z oddzielnych narzędzi. W środowiskach produkcyjnych znacznie ograniczam takie wydruki i zastępuję je licznikami w mapach lub zdarzeniami bufora pierścieniowego, aby uniknąć obciążenia i szumu.

Monitorowanie sieci: pakiety, przepływy, błędy

W środowisku sieciowym sprawdzam programy XDP i TC, odczytuję mapy ze stanami liczników oraz identyfikuję Hotspoty wzdłuż ścieżek danych. Korzystam z bpftool, aby uwidocznić pomijane reguły i scharakteryzować przepływy. Jeśli w filtrach pojawiają się błędne decyzje, zrzuty map pokazują rzeczywiste klucze i wartości. W ten sposób szybko znajduję różnice między oczekiwanym a rzeczywistym przetwarzaniem. Ten przegląd pomaga mi w doborze narzędzi do bardziej szczegółowej analizy Narzędzia analityczne eBPF, który znajduje zastosowanie w środowisku hostingowym beton klasyfikuje.

Warianty XDP/TC i widoczność za pomocą narzędzia bpftool net

W przypadku ścieżki sieciowej sprawdzam za pomocą polecenia “bpftool net” programy przypisane do interfejsów. W ten sposób mogę stwierdzić, czy XDP działa w trybie generycznym, natywnym czy offload oraz które haki TC (ingress/egress) są zajęte. Jeśli tryby są nieprawidłowe, koryguję opcje podłączenia lub parametry sterowników. Regularnie dokumentuję wyniki jako artefakt, aby zmiany w ścieżkach sieciowych zrozumiały pozostać.

W przypadku ścieżek Hotpath staram się wybierać krótkie ścieżki: programy XDP powinny podejmować decyzje na wczesnym etapie (pass/drop/redirect), a programy TC – konsolidować reguły i unikać zbędnych wyszukiwań. Na podstawie statystyk map oceniam jakość trafień, a zrzuty JIT dostarczają informacji o tym, czy wzorce skoków są niekorzystne. Jeśli ujawnią się koszty związane z kolejkowaniem lub sumami kontrolnymi, dostosowuję filtry i ponownie rozważam rozmieszczenie między XDP a TC.

Nadzór nad bezpieczeństwem i zgodność z przepisami

Używam programów eBPF do Proces-Uruchomienia, dostęp do plików i zdarzenia sieciowe, aby dostrzec wzorce istotne dla bezpieczeństwa. Za pomocą narzędzia bpftool sprawdzam, które programy są aktywne, gdzie się podłączają i czy reguły są stosowane. Jeśli punkty podłączenia są prawidłowe, sprawdzam zawartość map, aby udokumentować zastosowanie zasad. W przypadku podejrzanych zdarzeń sięgam po logi Verifier i kod bajtowy, aby zweryfikować logikę. Taki wgląd przyspiesza audyty i pozwala zespołom zrozumieć zachowanie agentów zrozumiały.

Uprawnienia, izolacja i modele bezpieczeństwa

Podczas pracy zwracam uwagę na jasno określone uprawnienia. W wielu systemach funkcje eBPF bez uprawnień są wyłączone; dlatego planuję korzystać z dedykowanych kont usługowych i konkretnych uprawnień. W zależności od wersji jądra stosuję uprawnienia CAP_BPF, CAP_PERFMON i CAP_NET_ADMIN, natomiast CAP_SYS_ADMIN wykorzystuję tylko wtedy, gdy jest to absolutnie konieczne. Izoluję procesy bpff według przestrzeni nazw, gdy kontenery wymagają własnych śladów, oraz wyznaczam granice grup cgroup w taki sposób, aby załączniki ukierunkowany mieć wpływ.

W celu zapewnienia zgodności z przepisami po wypełnieniu mapy wrażliwe mapy zamrażam za pomocą polecenia “bpftool map freeze”. Dzięki temu reguły są chronione przed zapisem, podczas gdy programy nadal mają do nich dostęp w trybie odczytu. Podczas audytów dokumentuję datę uruchomienia programu oraz punkty dołączania, dzięki czemu decyzje pozostają powtarzalne, nawet jeśli artefakty zostaną ponownie skompilowane.

Własne programy eBPF: ładowanie, dołączanie, debugowanie

Podczas programowania kompiluję pliki źródłowe w języku C za pomocą Clang do obiektów eBPF, ładuję je za pomocą bpftool i łączę je z Haki. Jeśli weryfikator zgłasza błąd, zapisuję log i krok po kroku ograniczam ryzykowne ścieżki. Sprawdzam przetłumaczony kod bajtowy i wynik JIT, aby ocenić sekwencje instrukcji. Jeśli wyniki są prawidłowe, zapisuję i odczytuję dane testowe za pomocą map oraz sprawdzam przypadki skrajne. Skraca to pętle sprzężenia zwrotnego i zapewnia sprawność mojego zestawu narzędzi zarówno do eksperymentów, jak i do produkcji znormalizowany.

Strategia CO-RE i stabilne artefakty

Aby kompilacje działały dłużej, stawiam na CO-RE. Włączam informacje BTF, korzystam z “gen vmlinux” i sprawdzam relokacje podczas ładowania. Jeśli pojawią się rozbieżności w strukturach jądra, dziennik weryfikatora wskazuje te miejsca. Staram się, aby programy były jak najbardziej ogólne, a zasady przechowuję w mapach. Zaleta: w przypadku zmian schematu aktualizuję tylko dane, a nie sam Kod. Dzięki Skeletons automatyzuję konfigurację, przypisywanie pinów i porządkowanie, co znacznie obniża wskaźnik błędów, zwłaszcza w potokach CI/CD.

Współpraca z zaawansowanymi narzędziami

Aby szybko osiągnąć sukces, stawiam przede wszystkim na BCC-skrypty i wykorzystuję je jako punkt wyjścia do bardziej szczegółowych analiz. Gdy tylko skrypt dostarcza przydatnych sygnałów, za pomocą narzędzia bpftool sprawdzam programy i mapy, na których się opiera. To przełączenie pokazuje mi, co faktycznie jest załadowane do jądra i jakie struktury danych są uruchomione. W ten sposób wyraźnie oddzielam warstwę abstrakcyjną od rzeczywistych obiektów. Aby uzyskać ogólny obraz sytuacji, warto zapoznać się z tymi zwięzłymi Narzędzia BCC, w której często zadawane pytania można rozwiązać za pomocą kilku poleceń okładka.

Najlepsze praktyki w zakresie obsługi

Ściśle oddzielam środowiska testowe od produkcyjnych, wcześnie gromadzę logi programu Verifier i dbam o to, by Cofnięcia Gotowe. Przed każdym wdrożeniem sprawdzam “bpftool feature”, aby upewnić się, że typ programu, helper i warianty mapy są zgodne z celem. Statystyki programów włączam do istniejącego systemu monitorowania, aby zapewnić widoczność obciążenia. Na bieżąco dokumentuję wszystkie punkty podłączenia, ponieważ tylko w ten sposób zespoły zachowują orientację. Kto chce zagłębić się w ten temat, znajdzie w Narzędzia analityczne eBPF dalsze impulsy dla Przepływy pracy.

Zarządzanie zasobami, czyszczenie i przywracanie

Używam pinów do tworzenia zdefiniowanych stanów i aktywnie je usuwam. Na wypadek cofnięcia zmian przechowuję poprzednią wersję w tej samej przestrzeni nazw (np. “/sys/fs/bpf/myapp/v1” i “/sys/fs/bpf/myapp/v2”). Przełączanie odbywa się poprzez ponowne podłączenie lub zmianę linku przy minimalnym czasie przestoju. Następnie usuwam stare linki i mapy, aby nie zajmowały zasobów lizanie. Przed usunięciem sprawdzam, czy nadal istnieją odwołania (“prog show”, “link list”, “map show”).

Aby uniknąć rozbieżności w konfiguracji, zamrażam mapy zawierające zasady i wprowadzam zmiany wyłącznie poprzez zdefiniowane wdrożenia. Aktualizacje zbiorcze planuję poza godzinami szczytu, monitoruję czas działania i liczbę błędów oraz potwierdzam pomyślne aktualizacje za pomocą drugiego “map dump”.

Automatyzacja i dane wyjściowe w formacie JSON

Flagi JSON i formaty nadające się do odczytu maszynowego sprawiają, że bpftool jest dobrym narzędziem możliwość tworzenia skryptów dla CI/CD, CMDB i audytów. Zabezpieczam kompilacje w sposób powtarzalny, dokumentuję skróty plików obiektowych i zapisuję ścieżki do plików bpffs. W ten sposób powiązuję wdrożenia z konkretnymi programami i mapami. Proste skrypty opakowujące zapisują raporty o stanie po każdej zmianie na konsoli oraz w artefaktach. Dzięki temu środowisko eBPF pozostaje trwale testowalny.

Budowanie zaufania: tagi, hashtagi i artefakty

Po załadowaniu odczytuję tag programu (“bpftool prog show id X”), który jest wyprowadzony z kodu bajtowego. Tag ten powiązuję w mojej bazie CMDB z numerem kompilacji i skrótem commitu. Podczas późniejszych kontroli porównuję oczekiwany tag z aktualnym – w ten sposób wykrywam rozbieżności bez konieczności uzyskiwania dostępu do oryginalnych plików binarnych. W przypadku map rejestruję typ, rozmiary kluczy i wartości oraz flagi, aby zmiany struktury podczas aktualizacji na czas pokaz.

bpftrace w praktyce

W przypadku śladów ad hoc korzystam z bpftrace, gdy kilka wierszy kodu ma szybko dostarczyć odpowiedzi. Uzyskany efekt sprawdzam następnie za pomocą bpftool, aby dokładnie zobaczyć programy, punkty przyłączenia i mapy. W ten sposób łączę wyrazistość z bliskością rdzenia i synchronizuję oba te punkty widzenia. Jako punkt wyjścia warto zapoznać się z tym krótkim przeglądem na temat bpftrace, który dobrze radzi sobie z typowymi zapytaniami ramuje. Gdy tylko wzorzec będzie gotowy, w razie potrzeby przenoszę go do zwięzłych programów w języku C.

Analiza błędów na podstawie logów programu Verifier

W przypadku odrzucenia przez weryfikatora najpierw szukam potencjalnych zero-odwołania, brak sprawdzania granic lub zbyt długie ścieżki. Upraszczam logikę, izoluję podejrzane wywołania funkcji pomocniczych i sprawdzam poprawność przesunięć. Pomocne jest zmniejszanie dużych map i dzielenie ścieżek o wysokim obciążeniu na wyraźnie wyodrębnione bloki. Zrzuty JIT pokazują mi, czy pętle niepożądanie się rozszerzają, czy też skoki okazują się nieefektywne. Z każdym krokiem liczba komunikatów o błędach maleje, aż program działa niezawodnie obciążenia.

Szybka identyfikacja typowych usterek

Gdy widzę komunikaty typu “invalid mem access” lub “R.. unbounded loop”, sprawdzam granice tablic, poprawność wskaźników oraz ograniczenia pętli. W przypadku problemów z CO-RE wskazówki sugerują brakujące lub nieodpowiednie dane BTF; weryfikuję plik “/sys/kernel/btf/vmlinux” i dostosowuję struktury docelowe. Jeśli ładowanie nie powiedzie się z powodu braku modułów pomocniczych, polecenie “feature probe” wyświetla dostępne moduły pomocnicze i typy map. Jeśli podczas tworzenia zrzutu pojawiają się problemy z JIT, sprawdzam, czy JIT jest włączony i czy opcje zabezpieczeń nie ograniczają wyjścia zapobiegać.

Jeśli załączniki się zawieszają, często przyczyną jest link, który nadal jest przypięty. Sporządzam listę linków, celowo je odpinam, a następnie usuwam przypięcia. W przypadku komunikatu “EBUSY” sprawdzam, czy inna instancja usługi utrzymuje obiekty w stanie otwartym, i planuję krótkie, skoordynowane przełączenie.

Perspektywy: bpftool i nowoczesna analiza jądra

Wraz z nowymi wersjami jądra pojawiają się nowe typy programów, narzędzia pomocnicze i Statystyki, a bpftool szybko odzwierciedla te postępy. Dlatego planuję poświęcić czas na regularne aktualizacje, aby narzędzia i dokumentacja były na bieżąco. Ulepszenia w JSON i nowe podpolecenia otwierają dodatkowe możliwości automatyzacji. Jednocześnie coraz lepiej funkcjonuje integracja ze stosami wysokiego poziomu, co ułatwia wdrażanie. Osoby aktywnie śledzące ten rozwój zyskują w zakresie diagnostyki, optymalizacji i Bezpieczeństwo Tempo.

Krótkie podsumowanie

bpftool wyświetla mi bezpośrednio Dostęp dotyczą programów eBPF i ich struktur danych oraz uwidacznia procesy zachodzące w jądrze. Wykrywam wąskie gardła, sprawdzam reguły bezpieczeństwa i tworzę własne ślady, bez konieczności modyfikowania jądra. Dzięki przejrzystej instalacji, jasnym testom i skryptom korzystanie z narzędzi pozostaje powtarzalne. Narzędzia wysokopoziomowe przyspieszają rozpoczęcie pracy, podczas gdy bpftool niezawodnie dokumentuje rzeczywiste obiekty. W ten sposób zapewniam obserwowalność i diagnostykę na solidnym poziomie, który w codziennej eksploatacji nośniki.