Прямой ответ
eBPF — технология ядра Linux, позволяющая запускать безопасные песочные программы внутри ядра по событиям (syscall/сетевой пакет/функция планировщика) — без модулей ядра, без перезагрузки, без изменения наблюдаемого приложения («агент в коде» не нужен — ядро само шлёт события — верификатор гарантирует безопасность программ — crash ядра исключён — поэтому eBPF пустили в прод); для разработчика eBPF — это рентген системы: задержки там, где их не видно (off-CPU время — «процесс ждёт диск/сеть/лок» — метрики CPU покажут 10% утилизации при p99 2 секунды — ожидание не CPU — профили-контекст), сетевые потоки между подами без tcpdump-раскопок (tcpdump-практика — Hubble/Cilium — L3/L4/L7-потоки с identity — «кто ходит на :5432» — ответ за секунды — NetworkPolicy-аудит), системные вызовы процесса (opensnoop/execsnoop — «что открывает/запускает контейнер» — харднинг-аудит — supply chain/аномалии — runtime-безопасность); практические инструменты (без написания своего eBPF — 90% нужд): bcc (набор готовых скриптов: execsnoop — новые процессы в реальном времени, opensnoop — открытия файлов, biolatency — гистограмма задержек диска (диск-диагностика), tcplife — жизни TCP-соединений с байтами/длительностью, funclatency — латентность функции ядра); bpftrace (однострочники на awk-подобном языке: bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }' — «кастомный трассинг за минуту» — диагностика-культура); профилировщики: py-spy/bcc-profile с eBPF-сэмплированием стеков (CPU-профили без изменения кода — непрерывно — continuous profiling — Pyroscope/Parca — eBPF-агент снимает стеки всех процессов — оверхед <1% — «профилирование всего парка всегда» — раньше — событие, теперь — фон); сеть: Cilium/Hubble (L3-L7-observability+политики — networkpolicy), Pixie/Coroot (авто-карта сервиса — трейсы из eBPF без инструментации кода — OpenTelemetry-дополнение — «трейсинг без SDK» — комплиментарно, не замена); границы честности: eBPF видит ядро и нативные стеки (Python/Java-фреймы — через интерпретатор-специфичные unwinders — py-spy/async-profiler — профили — «eBPF покажет строку Python» — с оговорками версий), требования (ядро 4.9+/практично 5.8+ — BTF/CO-RE — старые LTS-дистрибутивы — часть инструментов не работает — bpffeature-проверка), привилегии (CAP_BPF/CAP_PERFMON — не rootless-игрушка — прод-доступ через RBAC-контролируемые агенты — доступы); «нужен ли eBPF каждому» — нет: метрики/логи/трейсы покрывают 80% (три столпа), eBPF — следующие 15% («метрик нет, кода не изменить, прод живой» — off-CPU/сеть/безопасность) — инструмент диагностики-эскалации, не повседневность.
Практика: off-CPU анализ и сетевая видимость
Off-CPU (главный диагностический выигрыш): метрика «p99 = 2 с, CPU 12%» — классический тупик метрик; eBPF-подход: offcputime (bcc) — стеки ожиданий (где поток спал: futex — лок, io_submit — диск, tcp_recvmsg — сеть — «2 секунды — в connect() к внешнему API без таймаута» — таймауты — находка без единого лога приложения); flamegraph ожиданий (профили-визуализация — off-CPU graph — «широкая полоса — ssl-read» — визуальный приговор); связка с трейсингом: трейс показывает «спан B долгий», off-CPU — почему (ждёт диск против ждёт блокировку БД — блокировки — разные лечения); сеть (Hubble/Cilium UI): поток-граф сервисов в реальном времени («app→db 500 rps, app→legacy-api 3 rps — а мы думали, не ходим» — микросервисы-ревизия), дропы по NetworkPolicy («отбивается — какое правило» — networkpolicy-отладка), DNS-запросы пода («резолвит внешний домен — кто добавил зависимость» — supply chain — SBOM-контекст); аномалии/безопасность: falco-класс (eBPF-детекторы: shell в контейнере, неожиданный исходящий коннект, запись в /etc — runtime-сигналы — харднинг — «вторжение увидели» — не по логам через день); ограничения: eBPF-программы верифицируются (сложные циклы/структуры — ограничены — «напишу произвольную логику в ядре» — нет — песочница), оверхед на хай-частотных событиях (трассинг каждого пакета на 100k pps — измерять — ёмкость — выборочность/агрегация в ядре — eBPF для этого и спроектирован — карты-агрегаторы).
Практический сценарий: p99 1.8 секунды при живых метриках — eBPF за час
Контекст: API-сервис (Python/FastAPI — gunicorn-uvicorn), p99 вырос 300 мс → 1.8 с за неделю; метрики: CPU 15%, RAM ок, БД p95 12 мс (Prometheus — «всё зелёное, но медленно» — тупик); шаги: (1) трейсы (OTel) — долгий спан «внутри обработчика» без деталей — instrumented только HTTP/БД — «между спанами» — серая зона; (2) py-spy-сэмплинг на проде (30 секунд — on-CPU flamegraph — профили) — CPU-профиль чист (нет горячей функции — процесс не считает — ждёт); (3) offcputime -p <pid> 30 (bcc — eBPF) — flamegraph ожиданий: 78% off-CPU — в ssl_read → connect к reports.internal — внешний отчёт-сервис (HTTP-вызов без таймаута/трейсинга — «забытая интеграция» — httpx-таймауты); (4) проверка сети (Hubble — поток app→reports.internal — латентность коннекта 1.5 с — reports-сервис деградировал неделю назад — их проблема, наша — зависимость без защиты); (5) фикс у нас: таймаут 2 с + circuit breaker + трейс-инструмент вызова (OTel-спаны — «серая зона» закрыта) + кэш отчётов (Redis — 60 с TTL); p99 вернулся к 280 мс в день фикса (reports-сервис чинили неделю — наша латентность больше не его заложник — SLO-границы); (6) постмортем-выводы: «метрики+трейсы показали ГДЕ, eBPF — ПОЧЕМУ» (off-CPU — единственный инструмент, увидевший ожидание в неинструментированном коде — инцидент-runbook — пункт «p99 при низком CPU → offcputime»); попутно: bpftrace-однострочник (открытые файлы процесса) нашёл утечку fd (сокет-файлы не закрывались в том же отчёт-клиенте — «1024 fd к утру» — следующий инцидент предотвращён — graceful-лимиты); итог: час eBPF-диагностики против недели гаданий по метрикам — инструмент эскалации окупается в первый же «необъяснимый» инцидент — техдолг-знания — два человека в команде умеют — минимальный навык.
FAQ
eBPF — это опасно? Можно ли уронить прод? Дизайн безопасен: верификатор ядра проверяет программу до загрузки (отсутствие бесконечных циклов/небезопасных обращений — crash-класс исключён — «модуль ядра» и eBPF — разные уровни риска); риски реальны другие: оверхед (трассинг высокочастотных событий без агрегации — CPU на наблюдение — измерять до продового включения — ёмкость), привилегии агентов (CAP_BPF — компрометация eBPF-агента — серьёзна — доступы/RBAC — секреты), баги инструментов (bcc-скрипт с опечаткой в фильтре — мусор-вывод, не падение — диагностика-гигиена); практика: готовые инструменты (bcc/bpftrace/Cilium — проверены тысячами прод-инсталляций) на стейдже сначала (флаги-постепенность); «свой eBPF в прод» — только с экспертизой (CO-RE/верификатор-ограничения — отдельная специализация — большинству хватает экосистемы — выбор-инструментов).
Нужен ли eBPF, если есть метрики, логи и трейсы? Порядок диагностики: метрики (что деградировало — метрики) → трейсы (где в цепочке — OTel) → логи (что случилось — логи) → eBPF (почему на уровне системы — когда три столпа молчат: неинструментированный код, off-CPU-ожидания, ядро/сеть/диск — сценарий выше — «между спанами»); eBPF-классы задач, где столпы бессильны: off-CPU (ожидания — не CPU-метрика), сетевые потоки без SDK (Hubble — «трейсинг сети» — tcpdump-замена в k8s-масштабе), syscall-аудит (безопасность/runtime — логи приложения не пишут «я открыл файл»), профилирование без кода (continuous — Pyroscope); вывод: не замена, а четвёртый слой (системная видимость) — включается по эскалации или фоном (профилировщики/Hubble — дешевы — «всегда включено» — норма 2026).
Какие версии ядра и дистрибутивы нужны для eBPF-инструментов?
Минимумы: ядро 4.9 (базовый eBPF), practically — 5.8+ (BTF/CO-RE — переносимые инструменты без перекомпиляции под ядро — ring buffers — эффективность); дистрибутивы 2026: Ubuntu 22.04+/Debian 12/RHEL 9/современные Amazon Linux — всё из коробки (bcc/bpftrace в репозиториях — пакеты); старый LTS (CentOS 7/ядро 3.10) — eBPF практически нет («у половины парка старое ядро» — аргумент апгрейда ОС — миграция-серверов); k8s-контекст: eBPF-агенты (Cilium) — DaemonSet с hostPID/привилегиями (харднинг-баланс — доверенный агент — RBAC+обновления — зависимости); проверка готовности: bpftool feature probe (что поддерживает ядро — конфигурация — «не работает» — часто не eBPF, а старое ядро/отключённый BTF).
Как начать практически — с каких инструментов?
Порядок входа (ноутбук/стейдж — локальный стек): bcc-набор (opensnoop/execsnoop/biolatency/tcplife — «система под микроскопом» за вечер — диагностика — Ubuntu: apt install bpfcc-tools — суффикс -bpfcc); bpftrace (однострочники под конкретный вопрос — шпаргалка Brendan Gregg — «кастом без программирования»); offcputime на своём сервисе (сценарий выше — первый «вау» — ожидания становятся видимы — профили); Hubble в k8s-кластере (networkpolicy-аудит — сеть видна — «что ходит куда» — день настройки); continuous profiling (Pyroscope-агент — eBPF-сэмплинг — профили всех сервисов фоном — профилирование-культура); что НЕ делать первым: свой eBPF-код (libbpf/CO-RE — специализация — сначала экосистема), trivy-подобные security-комбайны без процесса (Trivy-процесс — инструмент без ритуала — шум); навык окупается в диагностике (сценарий-час против недели — incident — два умеющих в команде — достаточный минимум).
Источники: ebpf.io, Brendan Gregg (ebpf.html), bcc/iovisor — ссылки в шапке.