eBPF в 2026 году — уже не «экзотика», а рабочий инструмент для Linux observability и production troubleshooting. Он позволяет точечно подсветить ядро и приложения без перезагрузок и без сборки модулей. Но в реальном инциденте возникает вечный вопрос: чем пользоваться прямо сейчас — bpftrace, bpftool или старым добрым perf?
Разберём эти инструменты как набор «ключей» к разным дверям. Фокус — практика: что запускать, как не навредить продакшену, как читать результат и где чаще всего ошибаются.
Короткая ориентация: что это за инструменты
bpftrace — язык и рантайм для быстрых eBPF-скриптов в стиле one-liner. Это «швейцарский нож» для точечных вопросов: кто создаёт больше всего файлов, какие процессы чаще всего вызывают connect(), где системные вызовы «живут» дольше обычного.
bpftool — официальная утилита из дерева ядра, которая показывает и управляет объектами BPF: программы, карты (maps), ссылки (links), BTF, pinned-объекты в bpffs, а также параметры вроде JIT. Это «терминал диагностики состояния» eBPF в системе.
perf — классический профайлер и трассировщик. В 2026 он всё ещё актуален, потому что часто уже установлен, быстро даёт ответ на вопрос «где время CPU», умеет стеки и дружит с традиционными событиями (PMU, tracepoints). Важно: perf может использовать часть eBPF-возможностей (зависит от сборки и ядра), но остаётся отдельной экосистемой.
Как выбрать инструмент в инциденте: практическая матрица
Если упростить до оперативной логики админа/SRE, то выбор обычно такой:
- Нужно быстро ответить на конкретный вопрос («кто? сколько? как часто?») — берите bpftrace.
- Нужно понять, что уже загружено в eBPF и не ломает ли оно систему — берите bpftool.
- Нужно профилировать CPU/стек/горячие функции — чаще всего быстрее стартовать с perf.
Дальше — критерии, которые реально влияют в проде.
Скорость «от нуля до полезного вывода»
bpftrace выигрывает, когда вы понимаете, что измерять: один one-liner — и у вас уже топ процессов/событий. Но если вы не уверены, какие пробники доступны (tracepoints/USDT) и как они называются, время уйдёт на разведку.
perf выигрывает в задачах «CPU горит»: запустили perf top или короткий perf record и сразу видите горячие функции. Если же проблема не в CPU, а в ожиданиях (I/O, блокировки, сеть), perf может потребовать больше ручной работы.
bpftool не отвечает на «бизнес-вопрос», зато быстро показывает: eBPF в системе вообще жив? есть ли pinned-программы? растут ли карты? что и куда attach’ено? Это экономит часы, когда вы подозреваете оверхед/утечку из-за чужих BPF-программ (агенты наблюдаемости, security, CNI).
Риск и контроль воздействия
В production troubleshooting важно не усугубить. eBPF часто безопаснее «дебаг-патчей», но не волшебный: можно устроить сильный оверхед частыми событиями или дорогими агрегациями.
- bpftrace опасен, если повеситься на очень частые события и печатать каждое. Правильный стиль — агрегировать и печатать периодически.
- perf опасен слишком высокой частотой семплирования и «везде стеки», особенно на загруженных CPU.
- bpftool обычно минимально инвазивен: он чаще читает состояние. Но дамп больших карт может быть тяжёлым.
Требования к окружению (kernel, права, символы)
В 2026 стоп-факторы чаще не «поддерживает ли ядро eBPF», а более приземлённые вещи: доступ к BTF, наличие дебаг-символов, политика безопасности на проде (capabilities), ограничения контейнеров и доступ к tracefs/bpffs.
- bpftrace любит BTF и «чистое» окружение, иначе придётся тратить время на типы/смещения/ограничения.
- perf любит символы. Без них вы увидите горячие адреса/функции ядра, но анализ user space будет хуже.
- bpftool полезен почти всегда как базовый «инструмент инвентаризации».
Сценарии из продакшена: что запускать и зачем
Ниже — типовые ситуации. Команды даю в «минимальном» виде. Точные события и поля зависят от ядра, а в некоторых окружениях потребуется root или соответствующие capabilities.
Если вы только внедряете eBPF-диагностику как регулярную практику, держите под рукой отдельную шпаргалку по инструментам и их семантике: это помогает в стрессовой ситуации не вспоминать «как называется тот tracepoint».
По теме bpftrace и смежных утилит у нас есть отдельный материал: диагностика Linux через eBPF (bcc/bpftrace): практические примеры.
1) «CPU 100%»: быстро понять, кто ест процессор
Чаще всего проще начать с perf: это прямой профайлер. Два базовых режима — интерактивный топ и запись профиля на коротком окне.
perf topperf record -a -g -- sleep 30
perf reportЕсли нужно понять, что делает конкретный процесс, bpftrace тоже полезен: можно агрегировать частоту системных вызовов процесса по PID. Главное — не печатать каждое событие.
bpftrace -e 'tracepoint:syscalls:sys_enter_* /pid == 1234/ { @[probe] = count(); } interval:s:5 { print(@); clear(@); }'Как это читать: вы увидите, какие syscalls чаще всего вызываются. Это не заменяет flamegraph, но иногда мгновенно показывает «крутится в futex» или «тонет в openat/stat». Дальше решаете: профилировать глубже (perf + стеки) или копать ожидания.
2) «Задержки запросов выросли, CPU не горит»: искать блокировки, очереди, I/O
Классика: CPU может быть низким, а запросы стоят в ожидании диска/сети/локов. Тут bpftrace удобен для измерения латентности конкретных syscalls (например, read, write, fsync) — важно правильно выбрать точку и агрегировать.
Пример: измерим длительность fsync и соберём в гистограмму (идея важнее конкретного события):
bpftrace -e 'tracepoint:syscalls:sys_enter_fsync { @start[tid] = nsecs; } tracepoint:syscalls:sys_exit_fsync /@start[tid]/ { @lat = hist((nsecs-@start[tid])/1000); delete(@start[tid]); } interval:s:10 { print(@lat); clear(@lat); }'Если гистограмма уехала в миллисекунды или сотни миллисекунд — дальше идёте «по цепочке»: устройство и очередь, I/O scheduler, файловая система, dirty writeback, throttling от cgroup. perf обычно подключается позже, когда нужно понять, в каких функциях ядра тратится время при I/O.
3) «Похоже, eBPF уже кто-то использует»: инвентаризация через bpftool
На современных узлах eBPF часто уже загружен агентами (observability, network, security). Перед тем как запускать своё, полезно понять текущую картину: сколько программ, какие типы, не растут ли карты, нет ли pinned-объектов.
bpftool prog showbpftool map showbpftool link showЕсли «всего много» и есть подозрение на нагрузку, смотрите детали конкретной программы и привязку (где она висит: tracepoint/kprobe/cgroup/socket/tc/XDP и т.д.).
bpftool prog show id 123bpftool prog dump xlated id 123Практический смысл: вы не всегда можете «выключить агент», но можете собрать факты (корреляция нагрузки с ростом карты, тип attach, владелец по метаданным) и дальше точечно править конфигурацию агента или политику сбора.
4) «Сеть тормозит или есть всплески ошибок»: где смотреть
Сетевые проблемы — зона, где инструменты дополняют друг друга:
- bpftrace — быстро посчитать события по syscalls (
connect,accept,sendto) или tracepoints сетевого стека. - perf — понять, где CPU тратится в сетевом стеке (например, softirq/NET_RX) и получить стек.
- bpftool — увидеть BPF-влияние на сеть (XDP/tc/cgroup skb) и конкретные загруженные программы/линки.
Для старта «кто чаще всего делает connect»:
bpftrace -e 'tracepoint:syscalls:sys_enter_connect { @[comm] = count(); } interval:s:5 { print(@); clear(@); }'Дальше обычно нужен второй шаг: ловить ошибки на exit-событиях и считать частоту по кодам возврата. Подход тот же: фильтры, агрегаты, печать по интервалу.
Где bpftrace лучше perf, а где наоборот
bpftrace сильнее, когда:
- Нужна агрегация событий на лету: топы, гистограммы, счётчики, без долгой настройки.
- Вы ищете редкий, но дорогой системный вызов или всплеск ошибок.
- Нужно быстро проверить гипотезу «а правда ли это происходит».
perf сильнее, когда:
- Нужно CPU-профилирование со стеками и ответом «где время».
- Нужно работать с низкоуровневыми событиями (PMU): cache misses, stalls и т.д.
- Вы строите повторяемый процесс анализа (record/report, сравнения между релизами).
Если ваш инцидент связан с веб-нагрузкой (Nginx/PHP-FPM/БД), часто в итоге сходятся две линии: eBPF-проверка гипотез (латентности, ожидания) и «классический» тюнинг. По соседней теме может пригодиться: тюнинг PHP-FPM на VDS под нагрузкой.
Где bpftool незаменим: контроль, дебаг, «почему не работает»
bpftool редко «решает инцидент» сам по себе, но он критичен в двух случаях:
- Не запускаются eBPF-инструменты (ошибки верификатора, нет прав, нет BTF, нет доступа к файловым системам) — bpftool помогает понять контекст и ограничения.
- Нужно понять влияние уже загруженных BPF-программ — сколько их, какие типы, какие карты, есть ли pinned-объекты, как устроены links и точки attach.
bpftool также полезен как «универсальный формат фактов» для коммуникации: вы показываете команде безопасности/сетевикам список программ и точку attach без предположений.
Типовые ошибки в production troubleshooting (и как их избежать)
Ошибка 1: печатать каждое событие
На загруженной машине вывод в консоль сам станет проблемой. Правило: используйте агрегаты и интервалы печати. В bpftrace почти всегда лучше @[...] = count() и interval:s:N, чем printf() на каждом событии.
Ошибка 2: вешаться на слишком «горячие» точки без фильтров
Если вы трейсите все процессы и все syscalls, вы получите шум и оверхед. Сначала фильтруйте по pid, comm, cgroup, порту/адресу (если доступно), и только потом расширяйте охват.
Ошибка 3: путать «симптом» и «причину»
Много futex — не значит «проблема в futex». Обычно это симптом контеншена. Аналогично, рост write/fsync может быть следствием изменения логирования или параметров коммита в БД. Инструменты дают сигнал, причинно-следственную цепочку всё равно строит инженер.
Ошибка 4: игнорировать уже существующие eBPF-агенты
Часто на узле уже работают XDP/tc-программы, сборщики профилей, security-датчики. Они могут влиять на производительность, занимать лимиты (количество программ/карт/память) или мешать вашим экспериментам. Перед «тяжёлым» трейсингом сделайте короткую ревизию через bpftool.
Рекомендуемый workflow: как действовать на проде
- Стабилизировать: зафиксировать окно наблюдения, убедиться, что сбор не обрушит узел.
- Быстрый диагноз: perf для CPU-симптомов; bpftrace для задержек/ошибок/частоты syscalls; системные метрики (load, PSI, iowait) параллельно.
- Инвентаризация eBPF: bpftool, чтобы понимать, что уже загружено и где.
- Углубление: точечные bpftrace-скрипты с фильтрами и агрегацией; perf record для стеков там, где нужно «где время».
- Сбор артефактов: сохранить команды, вывод, версию ядра, ограничения и условия. Это ускорит постмортем и повторяемость диагностики.
Итоги: bpftrace vs bpftool vs perf в 2026
bpftrace — лучший выбор, когда нужна быстрая eBPF-диагностика и ответы в виде статистики «кто/сколько/как долго».
bpftool — инструмент контроля и правды о состоянии eBPF в системе: что загружено, куда attach’ено, что растёт и почему «не работает».
perf — король CPU-профилирования и анализа «где время» со стеками; в инциденте при высокой загрузке CPU часто даёт самый быстрый первый ответ.
В реальном troubleshooting это не конкуренты, а связка: perf (профиль) + bpftrace (точечная статистика) + bpftool (контроль окружения).
Если вы планируете регулярную low-level наблюдаемость и диагностику на своих узлах, закладывайте это в базу инфраструктуры: предсказуемые ресурсы, удобные права доступа и стабильное ядро. Для таких задач обычно выбирают отдельный VDS под сервисы и мониторинг, чтобы без сюрпризов держать оверхед в рамках.
