eBPF для сисадмина: мониторинг, безопасность и отладка без перезагрузки ядра

Мы в компании «СерверПро» — большой хостинг-провайдер, у нас целых 400 физических серверов. Наша команда из 6 инженеров поддерживала всю эту махину, используя привычные инструменты вроде top, iotop, tcpdump и strace. И вот однажды мы столкнулись с проблемой: на одном из серверов, где крутилось 200 контейнеров, периодически начинала проседать сеть. Представляете, tcpdump в таких случаях генерировал гигабайты трафика, а strace просто тормозил процессы аж на 40%!

eBPF, или extended Berkeley Packet Filter, — это такая классная технология, которая даёт нам возможность запускать изолированные программы прямо внутри ядра Linux. Самое крутое, что для этого не нужно ни менять исходники ядра, ни перезагружать систему! При этом, прежде чем загрузиться, каждая eBPF-программа обязательно проходит верификацию ядром — и именно это служит нашей гарантией безопасности.

Чем eBPF хорош именно для production:

• Минимальный overhead — 1-3% vs 30-50% у strace
• Безопасность — верификатор ядра проверяет каждую программу перед запуском
• Динамическая загрузка — подключайте и отключайте трейсинг на лету
• Универсальность — от трейсинга syscall до фильтрации сетевых пакетов и профилирования CPU

Для работы с eBPF нужно ядро Linux 5.8+ (а лучше 6.1+). Проверяем:

# Проверка версии ядра
uname -r
# 6.1.0-18-amd64

# Проверка поддержки eBPF
ls /sys/kernel/btf/vmlinux
# Если файл есть — BTF включён, bpftrace будет работать

Установка на Debian/Ubuntu:

# bcc — набор готовых инструментов на Python + C
apt install bpfcc-tools linux-headers-$(uname -r)

# bpftrace — высокоуровневый язык для однострочных трейсов
apt install bpftrace

# Проверяем
bpftrace --version
# bpftrace v0.20.0

Установка на RHEL/Rocky Linux:

dnf install bcc-tools bpftrace kernel-devel-$(uname -r)

Набор bcc включает десятки готовых инструментов. Самые полезные для ежедневной работы:

# Топ процессов по syscall — кто нагружает ядро
sudo syscount-bpfcc -t 5
# Показывает топ-10 syscall за 5 секунд

# Задержки блочного ввода-вывода — гистограмма
sudo biolatency-bpfcc -D
# Покажет распределение задержек по дискам

# Кто читает/пишет на диск прямо сейчас
sudo biotop-bpfcc
# PID    COMM         D MAJ MIN  DISK   I/O  Kbytes  AVGms
# 14882  postgres     R 259 0    nvme0  847   53424   0.28

# Сетевые соединения — кто куда подключается
sudo tcpconnect-bpfcc
# PID    COMM         IP SADDR          DADDR          DPORT
# 3912   nginx        4  10.0.0.5       10.0.0.20      5432

Для диагностики «СерверПро» использовали tcpretrans-bpfcc — инструмент, отслеживающий TCP-ретрансмиссии:

sudo tcpretrans-bpfcc
# TIME     PID  IP LADDR:LPORT   RADDR:RPORT   STATE
# 09:15:02 0    4  10.0.0.5:443  203.0.113.1:52341 ESTABLISHED
# 09:15:02 0    4  10.0.0.5:443  198.51.100.7:18923 ESTABLISHED

Выяснилось: один контейнер генерировал тысячи ретрансмиссий из-за неправильного MTU. Фикс — одна строка: ip link set eth0 mtu 1450.

Если говорить простыми словами, bpftrace — это как будто awk, только для ядра Linux. Мы можем писать с его помощью короткие, однострочные скрипты и трассировать абсолютно любые функции — будь то функции самого ядра или процессы в пользовательском пространстве.

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

# Гистограмма размеров read() по процессам
sudo bpftrace -e 'tracepoint:syscalls:sys_exit_read /args->ret > 0/ { @bytes[comm] = hist(args->ret); }'

# Задержка DNS-резолвинга
sudo bpftrace -e 'uprobe:/lib/x86_64-linux-gnu/libc.so.6:getaddrinfo { @start[tid] = nsecs; }
uretprobe:/lib/x86_64-linux-gnu/libc.so.6:getaddrinfo /@start[tid]/ { @dns_ms = hist((nsecs - @start[tid]) / 1000000); delete(@start[tid]); }'

# Трейс OOM killer — кто убивает процессы
sudo bpftrace -e 'kprobe:oom_kill_process { printf("OOM kill: %s (pid %d)\n", comm, pid); }'

Пример реальной отладки: PostgreSQL медленно отвечал, но EXPLAIN ANALYZE показывал быстрые запросы. Через bpftrace обнаружили, что fsync() блокировался на 200+ мс из-за заполненного RAID-кэша:

sudo bpftrace -e 'kprobe:vfs_fsync_range { @start[tid] = nsecs; }
kretprobe:vfs_fsync_range /@start[tid]/ {
    $dur = (nsecs - @start[tid]) / 1000000;
    if ($dur > 50) { printf("SLOW fsync: %s pid=%d %dms\n", comm, pid, $dur); }
    @fsync_ms = hist($dur); delete(@start[tid]);
}'

Традиционные iptables не масштабируются: при 10,000+ правил время обработки пакета растёт линейно. eBPF решает эту проблему через хеш-таблицы ядра — O(1) lookup вместо O(n).

Cilium — самый зрелый eBPF-based CNI для Kubernetes. Что он даёт:

• Network Policies на L3/L4/L7 — фильтрация по HTTP-путям, gRPC-методам, DNS-именам
• Transparent encryption — WireGuard или IPsec между нодами без конфигурации приложений
• Hubble — визуализация сетевого трафика между сервисами в реальном времени
• Bandwidth Manager — rate limiting на уровне pod без tc/HTB

# Установка Cilium в кластер Kubernetes
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.16.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# Проверка статуса
cilium status
# Cilium:          OK
# Hubble Relay:    OK
# Encryption:      Wireguard

L7-политика: разрешить frontend обращаться только к GET /api/products на backend:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/products"

План, по которому «СерверПро» внедрила eBPF на 400 серверах за 3 недели:

1. Неделя 1: пилот на 5 серверах — установка bcc-tools, обучение команды базовым командам
2. Неделя 2: автоматизация — Ansible-роль для установки bcc + bpftrace + готовые скрипты в /opt/ebpf-tools/
3. Неделя 3: интеграция с мониторингом — экспорт метрик eBPF в Prometheus через bpf-exporter

# /opt/ebpf-tools/check-retrans.sh — cron каждые 5 минут
#!/bin/bash
COUNT=$(timeout 30 tcpretrans-bpfcc 2>/dev/null | wc -l)
echo "tcp_retransmits $COUNT" | curl --data-binary @- http://pushgateway:9091/metrics/job/ebpf

Результаты через месяц: