eBPF для observability: диагностика ядра Linux без перекомпиляции и простоев

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет в эксплуатации Linux я повидал и strace, и perf, и kprobes с ручной сборкой модулей ядра. Но всё это меркнет на фоне того, что сегодня даёт eBPF. Когда нужно понять, какой процесс открывает странные TCP-соединения или почему конкретный запрос в PostgreSQL работает 30 секунд вместо 30 миллисекунд — у нас на практике именно eBPF-инструменты находят ответ за минуты там, где раньше уходили часы.

Что такое eBPF и зачем он вам

Extended Berkeley Packet Filter — это встроенная в ядро Linux виртуальная машина, которая позволяет запускать небольшие программы в привилегированном контексте, но при этом безопасно. Программу загружает userspace через системный вызов bpf(), ядерный верификатор проверяет её на корректность (нет бесконечных циклов, нет чтения за границами массивов), и дальше она цепляется к конкретному событию: системный вызов, tracepoint, kprobe, функция пользовательского процесса (uprobe).

Это революция по сравнению с классическим strace. strace переключает контекст на каждый системный вызов, ломая производительность приложения в 10-100 раз. eBPF работает внутри ядра, собирает статистику в лок-фри кольцевой буфер и выдаёт агрегированные данные в userspace. Оверхед — доли процента.

Установка инструментария

На современных дистрибутивах всё уже в пакетах. Ubuntu 22.04/24.04:

sudo apt install bpfcc-tools bpftrace linux-headers-$(uname -r)
sudo apt install libbpf-dev  # для разработки своих eBPF-программ

# Проверка доступности
sudo bpftrace -l | head
sudo bpftrace -e 'BEGIN { printf("eBPF works\n"); exit(); }'

Для Rocky Linux / RHEL:

sudo dnf install bcc-tools bpftrace kernel-headers

В Debian bookworm и openSUSE пакеты называются аналогично. Если вы на старом ядре (4.x) — обновляйтесь до 5.15+ LTS, иначе половина полезных хуков недоступна.

bpftrace: одностроковые запросы к ядру

bpftrace — это как awk для ядра. Пишете короткий скрипт, получаете результат. Мои любимые команды для ежедневной диагностики:

# Какие процессы открывают файлы прямо сейчас
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat {
  printf("%s %s\n", comm, str(args->filename));
}'

# Гистограмма времени выполнения read()
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
  tracepoint:syscalls:sys_exit_read /@start[tid]/ {
    @us = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
  }'

# Топ процессов по количеству соединений TCP
sudo bpftrace -e 'kprobe:tcp_connect {
  @connects[comm] = count();
} interval:s:10 { exit(); }'

Такие однострочники я часто использую, когда клиент звонит с жалобой «сервер тормозит, но непонятно почему». За 10 минут собираю картину: какие процессы больше всего дёргают диск, какие открывают файлы, какие ходят в сеть.

bcc-tools: готовые диагностические утилиты

bcc — это коллекция Python-скриптов с eBPF-программами внутри, которые решают типовые задачи. Установили пакет bpfcc-tools — получили 100+ готовых инструментов в /usr/sbin/.

# Запуск execsnoop и tcpconnect параллельно
sudo execsnoop-bpfcc &
sudo tcpconnect-bpfcc &

Диагностика медленного PostgreSQL: пошагово

Классическая задача: клиент жалуется, что SQL-запрос, который вчера летал, сегодня работает 40 секунд. Начинаем с biolatency-bpfcc, чтобы понять, диск ли тормозит:

sudo biolatency-bpfcc 10 6
# Показывает 6 отчётов по 10 секунд — гистограммы latency

Если распределение I/O нормальное (90% запросов меньше 1 мс) — диск ни при чём. Смотрим, что делает конкретный процесс postgres:

# Все системные вызовы postgres с PID 12345 и их длительности
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter /pid == 12345/ {
  @start[tid] = nsecs;
}
tracepoint:raw_syscalls:sys_exit /@start[tid]/ {
  @us[args->id] = hist((nsecs - @start[tid]) / 1000);
  delete(@start[tid]);
}'

Смотрим, в каком syscall процесс проводит больше всего времени, и дальше уже знаем, куда копать: futex (блокировки), recvfrom (ожидание сети), read (диск) или что-то ещё.

Сетевая observability: Cilium и не только

В Kubernetes-эпоху eBPF стал основой для современных сетевых решений. Cilium использует eBPF для:

• Сетевых политик без iptables (ускорение в 3-5 раз).
• Балансировки нагрузки kube-proxy через XDP.
• Observability сервис-меша без sidecar-прокси (Hubble).
• Шифрования трафика через WireGuard или IPsec.

Для отдельного сервера (не кластера) полезные сетевые eBPF-инструменты: tcplife-bpfcc (статистика по завершённым TCP-сессиям), gethostlatency-bpfcc (задержки DNS), sslsniff-bpfcc (расшифрованный HTTPS-трафик, если процесс использует OpenSSL).

Production-мониторинг на eBPF

Для постоянного мониторинга я использую комбинацию Pixie + Parca + Prometheus node_exporter с модулем node-exporter-textfile. Pixie автомагически инструментирует Kubernetes-кластер и показывает HTTP/SQL/gRPC запросы без изменения кода приложений. Parca даёт continuous profiling на eBPF — профили CPU всех процессов в реальном времени с оверхедом меньше 1%.

# Установка Pixie на кластер K8s
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"
px deploy

# Parca в Docker
docker run -d --privileged --pid host --network host \
  -v /sys/kernel/debug:/sys/kernel/debug \
  ghcr.io/parca-dev/parca-agent:v0.29.0

Кейс: поиск утечки дескрипторов на почтовом сервере

В июне 2025 года к нам пришёл клиент — почтовый сервер Postfix+Dovecot на 1500 ящиков. Раз в неделю сервер переставал принимать новые соединения, в логах — «Too many open files». Увеличение лимитов в /etc/security/limits.conf и systemd временно помогало, но через 6-9 дней проблема возвращалась. Стандартный lsof показывал сотни тысяч открытых файлов у процессов Dovecot, но какие именно — понять было сложно.

Запустили opensnoop-bpfcc -d 1200 | grep dovecot > /tmp/opens.log на 20 минут и увидели: процесс dovecot-auth открывает файл /var/lib/dovecot/auth-worker.sock и не закрывает его в одном из кодовых путей. Это оказался баг в старой версии Dovecot 2.3.16. Обновили до 2.3.21 — проблема ушла. Сервер: HP ProLiant DL360 Gen10 с Xeon Gold 6248, 128 ГБ RAM, в дата-центре МТС в Москве. Стоимость аудита и исправления — 48 000 руб., экономия клиенту — десятки часов ежемесячных ребутов.

Безопасность и eBPF

eBPF — мощный инструмент, и поэтому требует прав root или CAP_BPF. На production-серверах я всегда настраиваю:

• eBPF разрешён только для группы bpf_users, куда входят старшие инженеры.
• Логирование всех bpf()-системных вызовов через auditd.
• Запрет unprivileged BPF: sysctl kernel.unprivileged_bpf_disabled=1.
• Мониторинг загруженных программ: bpftool prog list.

# Текущие eBPF-программы
sudo bpftool prog list

# Карты (map'ы), которые они используют
sudo bpftool map list

FAQ — частые вопросы по eBPF

Что такое eBPF простыми словами?

Встроенная в ядро Linux виртуальная машина для трассировки и фильтрации, которая принимает программы от userspace и безопасно выполняет их в привилегированном контексте.

С какого ядра eBPF работает полноценно?

5.4+ для BTF/CO-RE, 5.10+ для полной экосистемы. Рекомендую Linux 5.15 LTS или новее.

Нагружает ли eBPF сервер?

Правильно написанные программы имеют оверхед 0.1-2%. Верификатор ядра блокирует опасный код.

Можно ли использовать eBPF на Windows?

Microsoft разрабатывает eBPF for Windows, но в 2025 он в раннем состоянии.

Что лучше: bcc или bpftrace?

bpftrace — для быстрых запросов. bcc — для production-инструментов.