Современный мониторинг Linux-систем давно перерос рамки простого наблюдения за нагрузкой процессора и использованием памяти. Когда речь заходит о высоконагруженных production-окружениях, где каждая миллисекунда задержки может стоить денег, инженерам нужен инструментарий совершенно иного уровня. Именно здесь на сцену выходит eBPF - технология, которая буквально переворачивает представление о том, как можно взаимодействовать с ядром операционной системы.
Что же делает эту технологию настолько особенной? Почему крупнейшие компании вроде Netflix и Google массово внедряют eBPF-инструменты на своих серверах? Ответ кроется в уникальном сочетании безопасности, производительности и невероятной гибкости, которое открывает перед системными администраторами и разработчиками возможности, о которых раньше можно было только мечтать.
Виртуальная машина внутри ядра
eBPF, или extended Berkeley Packet Filter, представляет собой встроенную виртуальную машину в ядре Linux, способную безопасно выполнять пользовательский код прямо в kernel space. Звучит рискованно? На самом деле нет. Каждая программа проходит строгую верификацию: специальный модуль проверяет отсутствие бесконечных циклов, валидность обращений к памяти и другие потенциально опасные операции.
История технологии началась с простого фильтра пакетов для tcpdump, но с 2014 года, когда в Linux 4.x появилась расширенная версия, возможности BPF выросли многократно. Теперь это полноценная платформа для трассировки системных вызовов, мониторинга сетевой активности, анализа работы планировщика и дисковых операций. Программы компилируются в байткод, загружаются через системный вызов bpf() и привязываются к различным событиям.
Архитектура eBPF основана на событийно-ориентированной модели. Программы могут прикрепляться к различным точкам хуков: системным вызовам, точкам входа и выхода функций, трейспойнтам ядра, сетевым событиям и многим другим. Если предопределенного хука не существует для конкретной задачи, можно создать kprobe (kernel probe) для динамической инструментации практически любой функции ядра или uprobe (user probe) для трассировки пользовательских приложений.
Ключевым элементом архитектуры являются BPF maps - структуры данных типа ключ-значение, которые служат для обмена данными между ядром и user space. Maps могут быть различных типов: хеш-таблицы, массивы, per-CPU карты для минимизации contention, LRU-карты и специализированные структуры вроде ring buffers для потоковой передачи событий. Эти карты позволяют eBPF-программам агрегировать данные в ядре и передавать в пользовательское пространство только итоговую информацию, что критически важно для производительности.
Преимущества перед классическими инструментами
Когда дело доходит до сравнения с традиционными утилитами вроде strace или perf, разница становится особенно очевидной. Запуск strace на высоконагруженном production-сервере может создать критические накладные расходы из-за необходимости использования ptrace с множественными переключениями контекста, в то время как eBPF-инструменты работают с минимальным влиянием на производительность. Как это достигается?
Главный секрет в том, что eBPF агрегирует данные непосредственно в ядре. Вместо того чтобы отправлять каждое событие в user space для обработки, программа может построить гистограмму, отфильтровать ненужную информацию или собрать статистику прямо на месте. Perf trace обеспечивает трассировку системных вызовов с низкими накладными расходами, но eBPF идет дальше, предлагая полностью программируемый интерфейс. Инструмент не трассирует каждый пакет, что добавляло бы слишком много накладных расходов, вместо этого он отслеживает только TCP-события сессий, которые происходят гораздо реже.
Результаты впечатляют: правильно написанные eBPF-трассировщики демонстрируют накладные расходы менее одного процента даже при непрерывной работе. Это позволяет использовать их в продакшене круглосуточно, получая детальную телеметрию без риска негативно повлиять на систему. JIT-компиляция байткода в нативные инструкции для каждой архитектуры процессора обеспечивает производительность, близкую к нативному коду. Ранняя фильтрация прямо в ядре - возможность применять предикаты вроде "только для cgroup X", "только для PID namespace Y" или "только TCP state=ESTABLISHED" - минимизирует объем данных, копируемых в user space.
BCC как точка входа
BPF Compiler Collection - это именно тот фреймворк, который делает работу с eBPF доступной для широкой аудитории. Написанный на основе LLVM, он позволяет создавать инструменты, где C-код для ядра встраивается в Python-скрипты. Звучит необычно? Возможно. Но такой подход открывает удивительную гибкость.
В репозитории BCC находится более 100 готовых утилит, каждая из которых решает конкретную задачу. Хотите понять, какие процессы открывают определенный файл? Запустите opensnoop. Нужно отследить медленные операции с файловой системой? Для этого есть семейство инструментов вроде ext4slower или xfsslower. Интересует распределение задержек дисковых операций? Biolatency построит гистограмму за считанные секунды.
Установка BCC на современных дистрибутивах Linux обычно сводится к одной команде:
# Ubuntu/Debian
sudo apt-get install bpfcc-tools
# RHEL/CentOS
sudo yum install bcc-tools
# Проверка установки
ls /usr/share/bcc/tools/
Требования к версии ядра довольно мягкие - начиная с 4.1, хотя для доступа ко всем возможностям рекомендуется 4.9 и выше. Необходимые конфигурации ядра:
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_HAVE_EBPF_JIT=y
# Проверка флагов ядра
grep -E 'CONFIG_BPF=y|CONFIG_BPF_SYSCALL=y|CONFIG_BPF_JIT=y' /boot/config-$(uname -r)
Практика дискового мониторинга
Дисковый ввод-вывод часто становится узким местом в высоконагруженных системах. Традиционные методы диагностики либо дают слишком общую картину, либо создают неприемлемый overhead. BCC меняет правила игры.
Biolatency - это инструмент для построения гистограмм задержек блочных устройств. Он перехватывает события начала и завершения I/O-запросов, измеряет время между ними и формирует распределение по степенным интервалам:
# Базовый запуск с интервалом обновления 1 секунда
sudo biolatency -mT 1
# Пример вывода:
# Tracing block device I/O... Hit Ctrl-C to end.
# 21:33:40
# msecs : count distribution
# 0 -> 1 : 69 |****************************************|
# 2 -> 3 : 16 |********* |
# 4 -> 7 : 6 |*** |
# 8 -> 15 : 21 |************ |
# 16 -> 31 : 16 |********* |
# 32 -> 63 : 5 |** |
# 64 -> 127 : 1 | |
# Разделение по дискам
sudo biolatency -D
# Использование микросекунд вместо миллисекунд
sudo biolatency -u
Для детального анализа существует biosnoop. Этот инструмент показывает каждую дисковую операцию в реальном времени: временную метку, имя процесса, PID, устройство, тип операции (R/W), сектор, размер в байтах и латентность. Выявить "шумного соседа", который генерирует аномальную нагрузку на диск, с таким инструментом - дело нескольких минут:
sudo biosnoop
# Пример вывода:
# TIME(s) COMM PID DISK T SECTOR BYTES LAT(ms)
# 0.000004001 supervise 1950 xvda1 W 13092560 4096 0.74
# 0.000178002 supervise 1950 xvda1 W 13092432 4096 0.61
# 0.001469001 supervise 1956 xvda1 W 13092440 4096 1.24
# Фильтрация по устройству
sudo biosnoop -d sda
# Отображение времени в очереди
sudo biosnoop -q
Дополнительные инструменты для анализа I/O:
# Распределение размеров I/O операций
sudo bitesize
# Статистика page cache
sudo cachestat
# HITS MISSES DIRTIES READ_HIT% WRITE_HIT% BUFFERS_MB CACHED_MB
# 1074 44 13 94.9% 2.9% 1 223
# 2195 170 8 92.5% 6.8% 1 143
# Медленные операции ext4
sudo ext4slower 10 # операции дольше 10ms
Сетевая трассировка без накладных расходов
Когда речь заходит о мониторинге TCP-соединений, традиционные подходы вроде tcpdump захватывают каждый пакет, создавая огромный поток данных. Эти инструменты не являются обертками над tcpdump, они не трассируют каждый пакет, чтобы затем фильтровать SYN-пакеты. Вместо этого BCC-утилиты работают на уровне функций ядра, перехватывая только значимые события.
Tcpconnect трассирует функцию connect() ядра вместо захвата и фильтрации пакетов, показывая каждую исходящую попытку подключения с PID процесса, именем команды, IP-адресами источника и назначения, портом:
sudo tcpconnect
# Пример вывода:
# PID COMM IP SADDR DADDR DPORT
# 1479 telnet 4 127.0.0.1 127.0.0.1 23
# 1469 curl 4 10.201.219.236 54.245.105.25 80
# 31346 curl 4 192.0.2.1 198.51.100.16 80
# 31361 isc-worker00 4 192.0.2.1 192.0.2.254 53
# С временными метками
sudo tcpconnect -t
# Показать номера портов источника
sudo tcpconnect -p
# Фильтрация по порту назначения
sudo tcpconnect -P 80
Аналогично работает tcpaccept для входящих соединений - он отслеживает момент, когда соединение переходит в состояние ESTABLISHED после завершения трехстороннего рукопожатия:
sudo tcpaccept
# PID COMM IP RADDR RPORT LADDR LPORT
# 907 sshd 4 192.168.1.5 22 192.168.1.100 4422
# 907 sshd 4 10.0.0.5 22 10.0.0.100 4422
Tcpconnlat измеряет латентность установления соединения - время между отправкой SYN и получением ответа:
sudo tcpconnlat
# PID COMM IP SADDR DADDR DPORT LAT(ms)
# 32151 isc-worker00 4 192.0.2.1 192.0.2.254 53 0.60
# 32155 ssh 4 192.0.2.1 203.0.113.190 22 26.34
# 32319 curl 4 192.0.2.1 198.51.100.59 443 188.96
Tcpretrans выявляет повторные передачи пакетов, что часто указывает на проблемы в сети:
sudo tcpretrans
# Включение информации о состоянии TCP
sudo tcpretrans -s
# Показ трассировок стека
sudo tcpretrans --stack
# Фильтрация по IP
sudo tcpretrans -i 192.168.1.1
Каждый раз, когда ядро сбрасывает TCP-пакеты, tcpdrop отображает детали соединения, включая трассировку стека ядра, которая привела к сброшенному пакету:
sudo tcpdrop
# TIME PID IP SADDR:SPORT > DADDR:DPORT STATE (FLAGS)
# 13:28:39 32253 4 192.0.2.85:51616 > 192.0.2.1:22 CLOSE_WAIT (FIN|ACK)
# b'tcp_drop+0x1'
# b'tcp_data_queue+0x2b9'
Tcplife обобщает жизненный цикл TCP-сессий:
sudo tcplife
# Фильтрация по локальному порту
sudo tcplife -L 80
# PID COMM LADDR LPORT RADDR RPORT TX_KB RX_KB MS
# 31482 nginx 10.0.0.1 80 10.0.0.5 45654 0 0 0.23
# 31482 nginx 10.0.0.1 80 10.0.0.5 45655 2 24 65.50
Дополнительные TCP-инструменты:
# Состояния TCP-соединений и переходы
sudo tcpstates
# Агрегация трафика по подсетям
sudo tcpsubnet 192.0.2.0/24
# Top активных TCP-соединений по throughput
sudo tcptop
# Трассировка connect, accept и close событий
sudo tcptracer
Файловые операции под микроскопом
Opensnoop - один из самых популярных инструментов BCC, который трассирует все вызовы open() и openat() в системе:
sudo opensnoop
# Пример вывода:
# PID COMM FD ERR PATH
# 12345 bash 3 0 /etc/passwd
# 25548 gnome-shell 33 0 /proc/self/stat
# 1821 systemd-udevd 6 0 /sys/devices/virtual/net/lo/uevent
# С временными метками
sudo opensnoop -t
# Фильтрация по имени процесса
sudo opensnoop -n bash
# Фильтрация по PID
sudo opensnoop -p 1234
# Показать только неудачные открытия
sudo opensnoop -x
# Фильтрация по паттерну имени файла
sudo opensnoop -n '*.log'
Семейство инструментов *slower фильтрует операции файловой системы, показывая только те, что превышают заданный порог латентности:
# Медленные операции ext4 (более 10ms)
sudo ext4slower 10
# Медленные операции XFS
sudo xfsslower 10
# Медленные операции Btrfs
sudo btrfsslower 10
# Медленные операции ZFS
sudo zfsslower 10
Cachestat предоставляет статистику работы page cache - соотношение попаданий и промахов, количество "грязных" страниц:
sudo cachestat
# Вывод каждые 5 секунд
sudo cachestat 5
# HITS MISSES DIRTIES READ_HIT% WRITE_HIT% BUFFERS_MB CACHED_MB
# 1074 44 13 94.9% 2.9% 1 223
# 2195 170 8 92.5% 6.8% 1 143
# 182 53 56 53.6% 1.3% 1 143
Путь к собственным инструментам
Готовые утилиты BCC покрывают большинство типовых задач, но настоящая сила технологии раскрывается, когда нужно что-то специфическое. Создание собственного инструмента начинается с понимания архитектуры: C-код для ядра встраивается в Python-скрипт, который управляет загрузкой, считыванием данных и выводом результатов.
Простейший пример - трассировка системного вызова execve для отслеживания запуска процессов:
#!/usr/bin/python
from bcc import BPF
# eBPF программа на C
bpf_text = """
#include <uapi/linux/ptrace.h>
int trace_execve(struct pt_regs *ctx) {
char comm[16];
bpf_get_current_comm(&comm, sizeof(comm));
bpf_trace_printk("Process started: %s\\n", comm);
return 0;
}
"""
# Загрузка и компиляция eBPF кода
b = BPF(text=bpf_text)
# Прикрепление к tracepoint sys_enter_execve
b.attach_tracepoint(tp="syscalls:sys_enter_execve", fn_name="trace_execve")
print("Tracing execve... Hit Ctrl-C to end.")
# Чтение и вывод событий
try:
b.trace_print()
except KeyboardInterrupt:
print("Detaching...")
Более сложный пример с использованием BPF maps для подсчета вызовов по процессам:
#!/usr/bin/python
from bcc import BPF
bpf_text = """
#include <uapi/linux/ptrace.h>
// Определение BPF map для подсчета
BPF_HASH(counts, u32);
int trace_syscall(struct pt_regs *ctx) {
u32 pid = bpf_get_current_pid_tgid() >> 32;
u64 zero = 0, *val;
val = counts.lookup_or_try_init(&pid, &zero);
if (val) {
(*val)++;
}
return 0;
}
"""
b = BPF(text=bpf_text)
b.attach_kprobe(event=b.get_syscall_fnname("openat"), fn_name="trace_syscall")
print("Counting openat() calls by PID... Hit Ctrl-C to end.")
try:
while True:
time.sleep(1)
print("\n%-10s %s" % ("PID", "COUNT"))
counts = b["counts"]
for k, v in sorted(counts.items(), key=lambda c: c[1].value):
print("%-10d %d" % (k.value, v.value))
counts.clear()
except KeyboardInterrupt:
pass
Пример трассировки с гистограммой латентности:
#!/usr/bin/python
from bcc import BPF
from time import sleep
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <linux/blkdev.h>
// Гистограмма для латентности
BPF_HISTOGRAM(dist);
int trace_req_start(struct pt_regs *ctx, struct request *req) {
u64 ts = bpf_ktime_get_ns();
req->start_time_ns = ts;
return 0;
}
int trace_req_completion(struct pt_regs *ctx, struct request *req) {
u64 ts = bpf_ktime_get_ns();
u64 delta = ts - req->start_time_ns;
// Сохранение в гистограмму (микросекунды)
dist.increment(bpf_log2l(delta / 1000));
return 0;
}
"""
b = BPF(text=bpf_text)
b.attach_kprobe(event="blk_start_request", fn_name="trace_req_start")
b.attach_kprobe(event="blk_mq_start_request", fn_name="trace_req_start")
b.attach_kretprobe(event="blk_account_io_done", fn_name="trace_req_completion")
print("Tracing block I/O... Hit Ctrl-C to end.")
try:
sleep(99999999)
except KeyboardInterrupt:
print()
b["dist"].print_log2_hist("usecs")
Начинающим рекомендуется изучить исходники существующих инструментов из директории bcc/tools. Там видно, как организованы maps, как работают фильтры, как обрабатываются аргументы командной строки. Документация в файлах *_example.txt содержит скриншоты, объяснения и реальные примеры использования.
Туториал проводит через одиннадцать инструментов: execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans, runqlat и profile. Это отличная отправная точка для понимания возможностей.
Альтернативой BCC является bpftrace - высокоуровневый язык для быстрой диагностики, вдохновленный DTrace и awk:
# Подсчет системных вызовов по процессам
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[comm] = count(); }'
# Гистограмма латентности read()
sudo bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; }
kretprobe:vfs_read /@start[tid]/ { @ns = hist(nsecs - @start[tid]); delete(@start[tid]); }'
# Трассировка TCP-подключений
sudo bpftrace -e 'kprobe:tcp_v4_connect { printf("%s connecting to %d\\n", comm, arg1); }'
Экосистема и перспективы
eBPF развивается стремительно. В 2024-2025 годах появились новые возможности: BPF tokens для более гибкого управления правами, BPF arena для работы с пользовательской памятью, улучшенная поддержка BTF (BPF Type Format) для Compile Once, Run Everywhere. В 2024 году BCC добавил поддержку информации о типах BTF, что означает, что скрипты BCC могут напрямую обращаться к полям структур ядра в CO-RE-подобной манере, если доступен BTF.
Компании продолжают инвестировать в eBPF для решения критически важных задач. От оптимизации сетевых стеков до runtime security мониторинга, от непрерывного профилирования до детектирования аномалий - технология проникла во все аспекты современной инфраструктуры. Cilium использует eBPF для сетевого управления в Kubernetes, Falco - для intrusion detection, Pixie - для application-level observability без изменения кода приложений.
Улучшения в BTF для пользовательских программ сделали раскрутку стека через eBPF еще более надежной, расширяя использование таких профайлеров на языки вроде Go, Java с поддержкой JIT-символов. С прикреплением eBPF к perf events можно захватывать kernel и user-space стеки по всей системе с низкими накладными расходами. Поскольку сэмплирование и раскрутка стека происходят в контексте ядра благодаря BPF stack trace maps и BTF, влияние на систему минимально и последовательно.
Путь к мастерству в eBPF не быстрый, но вознаграждение соответствует усилиям. Возможность создавать инструменты, которые работают в продакшене с минимальными накладными расходами, анализировать системное поведение на уровне, недоступном традиционным методам, и решать проблемы, которые раньше казались неразрешимыми, делает изучение этой технологии стоящим вложением времени. BCC открывает дверь в этот мир, предоставляя готовые решения и фундамент для создания собственных инструментов, адаптированных под специфические требования каждой конкретной инфраструктуры.
Канал сайта в Telegram
Канал сайта на YouTube