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

Привет! Я Евгений Семёнов, директор ITFresh. За мои 15 с лишним лет в эксплуатации Linux я повидал многое: работал и со strace, и с perf, и даже с kprobes, когда приходилось вручную собирать модули ядра. Но поверьте, всё это лишь бледная тень того, что сегодня умеет eBPF. Только представьте: вам срочно нужно выяснить, какой процесс вдруг полез открывать подозрительные TCP-соединения? Или почему конкретный запрос в PostgreSQL вдруг выполняется 30 секунд вместо обычных 30 миллисекунд? По нашей практике, именно eBPF-инструменты дают ответ за считанные минуты. Раньше на такие расследования уходили часы. Теперь? Раз — и готово!

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

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

Да, это настоящая революция. Без преувеличения! Особенно если вспомнить старый добрый 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% запросов укладываются в миллисекунду — значит, диск тут ни при чём. Тогда смотрим, чем занят конкретный процесс PostgreSQL:

# Все системные вызовы 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]);
}'

Мы сразу видим, в каком системном вызове процесс зависает дольше всего. И это, поверьте, сразу подсказывает, куда копать: может быть, это 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 всех процессов в реальном времени. И самое приятное: оверхед при этом — минимальный, меньше одного процента!

# Установка 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. На продакшен-серверах я всегда подхожу к настройке с особой тщательностью, уделяя внимание следующему:

• 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-инструментов.