Linux: tcpdump и lsof — это прошлое. Заглядываем в ядро с eBPF

Когда top, iotop и lsof бессильны, продвинутый инженер использует eBPF (extended Berkeley Packet Filter). Это технология, которая позволяет выполнять ваш код (безопасные "скрипты") прямо внутри ядра Linux, не меняя его.

Это как strace или tcpdump, но без гигантских накладных расходов и с безграничными возможностями. bpftrace — это самый простой способ начать.

Три убойных bpftrace one-liner'а, которые заменят вам 5 утилит:

Какие файлы открывает каждый процесс в системе? (в реальном времени):

Bash

# (Аналог `lsof` на стероидах)
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

Кто сейчас создаёт TCP-соединения? (мощнее netstat):

Bash

# Показываем PID, имя процесса и целевой IP/порт
sudo bpftrace -e 'tracepoint:sock:inet_sock_set_state /args->newstate == TCP_SYN_SENT/ { @[pid, comm] = count(); }'

Какие execve() вызовы происходят? (мониторинг запуска процессов):

Bash

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s\n", str(args->argv[0])); }'

Взгляд архитектора: eBPF — это будущее Observability (наблюдаемости). Это не просто "еще один инструмент", это платформа. На ней построены такие гиганты, как Cilium (сеть в Kubernetes) и Falco (runtime-безопасность). Понимание eBPF — это прямой путь к уровню SRE и архитектора распределенных систем.

#linux #ebpf #sre #observability #devops #bpftrace #команды #architect

🐧 Linux: bpftrace — Твой рентген для ядра

Привет, коллеги! Если ты когда-нибудь бился над проблемой, которую не видят логи и не ловит strace, значит, пришло время заглянуть глубже. Инструмент bpftrace позволяет писать однострочники, которые вытаскивают данные прямо из функций ядра в реальном времени.

1. Ноль оверхеда: В отличие от тяжелых отладчиков, bpftrace практически не грузит систему. Можно безопасно запускать на боевом сервере под нагрузкой.
2. Универсальность: Хочешь увидеть, какие файлы открывает конкретный процесс? Или почему сетевой пакет дропается на уровне стека TCP? Легко.

Практика (однострочники на вес золота):

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

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

Зачем это нужно:

Чтобы перестать гадать. Когда сервер тормозит, а CPU и RAM в норме, bpftrace покажет, что, например, процесс застревает в ожидании блокировки диска или тратит вечность на переключение контекста. Это высший пилотаж траблшутинга.

#linux #ebpf #bpftrace #performance #troubleshooting #admin_future

🐧 Linux: eBPF-трейсинг вместо strace — хирургия без анестезии

Коллеги, когда в 3 ночи продакшн-сервис начинает вести себя странно, первый рефлекс — запустить strace на процесс. И вот ты сидишь, смотришь в поток syscall-ов, теряешь контекст, а overhead от strace в худшем случае убивает процесс быстрее, чем сам баг.

В 2026 году так делать стыдно. Добро пожаловать в bpftrace — если strace это кувалда, то bpftrace это эндоскоп.

Хочешь знать, какие файлы открывает конкретный процесс, сколько времени он тратит в ядре и где реально лежит латентность — без остановки сервиса и почти без overhead:

# Все открываемые файлы процессом nginx в реальном времени
bpftrace -e '
  tracepoint:syscalls:sys_enter_openat
  /comm == "nginx"/
  {
    printf("%s -> %s\n", comm, str(args->filename));
  }
'

# Латентность read() по перцентилям — находим I/O-узкое место
bpftrace -e '
  tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
  tracepoint:syscalls:sys_exit_read  /@start[tid]/
  {
    @lat = hist(nsecs - @start[tid]);
    delete(@start[tid]);
  }
'

Зачем это нужно:
Бизнес платит за uptime, а не за твои ночные медитации над strace-логом. bpftrace работает в ядре, не требует перезапуска процессов, не ломает продакшн и даёт гистограммы латентности за секунды. Когда Роман спрашивает "в чём причина деградации?", у тебя есть ответ с цифрами, а не с "ну, мы смотрим".

Итог: strace незаменим для разработки. Но в живом продакшне — только eBPF. Это разница между вскрытием и МРТ.

#linux #ebpf #bpftrace #performance #sysadmin #admin_future