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

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