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 (SRE): Ваш Prometheus — "слепой". Встречаем Parca

Боль: Ваш Prometheus + Grafana показывают: "CPU spike at 14:30". И что? Вы знаете, что был всплеск, но вы не знаете, ПОЧЕМУ. Какая функция в вашем Python/Go/Rust-коде "съела" CPU?

Реакция админа: "Перезапущу pod, наверное, 'глюк'".
Реакция SRE: "Мне нужен непрерывный профилировщик".

Parca — это "Prometheus для профилирования". Он построен на eBPF и непрерывно (с почти нулевым оверхедом) сканирует CPU и память всех ваших процессов в системе.

Киллер-фича: Вы можете выбрать "спайк" CPU на Grafana, а затем "провалиться" в Parca и увидеть "Flame Graph" (огненный граф) — точную карту, показывающую, что function: process_payment() заняла 45% CPU в этот момент.

Взгляд архитектора: Вы переходите от "Мониторинга" (знать, что сломалось) к "Observability" (понимать, почему сломалось). Parca — это ваш "микроскоп", который находит "раковую опухоль" в коде, а не просто измеряет "температуру".

#linux #sre #ebpf #parca #observability #performance #architect #гайд

🧠 eBPF: Почему все о нем говорят?

Если вы слышите слово eBPF из каждого утюга, но боитесь спросить, что это — объясняем за 30 секунд.

Раньше, чтобы добавить новую фичу в ядро Linux (или глубоко отладить его), нужно было писать модуль ядра (Kernel Module). Ошибка в модуле = Kernel Panic (синий экран смерти).

eBPF (Extended Berkeley Packet Filter) — это безопасная виртуальная машина прямо внутри ядра Linux. Она позволяет запускать ваши скрипты (песочницу) в пространстве ядра без риска обрушить систему и без пересборки ядра.

Что это дает админу в 2025:

Супер-мониторинг: Утилиты нового поколения (типа bcc-tools) видят каждый чих системы, не нагружая её.

Сетевая магия: Инструменты типа Cilium фильтруют пакеты быстрее, чем iptables, потому что делают это до того, как пакет попадет в сетевой стек.

Попробовать прямо сейчас: Поставьте bpfcc-tools (Ubuntu) или bcc-tools (CentOS). Запустите execsnoop. Вы увидите каждый новый процесс, запускаемый в системе в реальном времени.

#linux #kernel #ebpf #future #architecture #learning

🛡️ Security: Рентген для ядра. eBPF вместо гадания на логах

В 2026-м копаться в `strace` или `tcpdump` на высоконагруженном сервере — это как пытаться замерить пульс у бегущего спринтера, вставляя ему палки в колеса. Сервис либо упадет от оверхеда, либо вы утонете в гигабайтах мусора. Когда база «лагает», а сеть «тупит», нам нужны точные ответы, а не догадки.

Техническая суть:
Используем eBPF (Extended Berkeley Packet Filter). Это технология, которая позволяет запускать микропрограммы прямо внутри ядра Linux без его пересборки или загрузки модулей.

Под капотом: Мы вешаем «хуки» на системные вызовы (kprobes) или функции в пользовательском пространстве (uprobes). eBPF-программа собирает статистику в реальном времени с нулевым влиянием на производительность. Вы видите всё: от задержек записи на диск конкретным процессом до того, какой именно микросервис рвет TCP-сессию.

Практика:
Используем bpftrace, чтобы мгновенно найти, кто «насилует» диск медленными запросами (более 10 мс):

# Запускаем однострочник, который строит гистограмму задержек I/O
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } 
             kretprobe:vfs_read /@start[tid]/ { 
                 $lat = (nsecs - @start[tid]) / 1000000; 
                 if ($lat > 10) { @[comm] = lhist($lat, 0, 100, 10); }
                 delete(@start[tid]); 
             }'

# На выходе получаем четкую картину:
# @[postgres]:
# [10, 20)      |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| 152
# [20, 30)      |@@@@                                | 18
# [50, 60)      |@                                   | 2

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

Обнаруживаем «невидимые» проблемы: блокировки в ядре, микро-всплески трафика или утечки дескрипторов. В эпоху Cloud-Native и сложных распределенных систем это единственный способ не сойти с ума при поиске иголки в стоге сена.

#security #ebpf #linux #performance #monitoring #admin_future

🐧 Linux: XDP — Аннигиляция пакетов на входе в «Цифровую крепость»

Привет, коллеги! Сегодня четверг, 12 марта 2026 года, и если ваш сетевой стек до сих пор захлебывается от входящего мусора, пока iptables задумчиво перебирает цепочки правил, у меня для вас плохие новости. В эпоху 400-гигабитных каналов и повсеместного IPv6 классический путь пакета через всё ядро Linux — это непозволительная роскошь.

Техническая суть:

Мы переходим на XDP (eXpress Data Path). Это база для современного сетевого админа. XDP позволяет запускать eBPF-код прямо в контексте драйвера сетевой карты, до того, как ядро вообще начнет создавать структуру `sk_buff`.

Под капотом: Пакет перехватывается на уровне RX-очереди. Мы можем либо пробросить его дальше (XDP_PASS), либо мгновенно аннигилировать (XDP_DROP), либо отправить обратно (XDP_TX). Это дает нам производительность, близкую к DPDK, но без необходимости писать драйверы в пользовательском пространстве и терять интеграцию с ОС.

Практика:

В 2026-м мы не пишем байт-код руками. Используем современные обертки для быстрой фильтрации DDoS на подлете:

# 1. Устанавливаем xdp-tools (стандарт для современных дистрибутивов)
# 2. Вешаем фильтр, который будет дропать всё, что не соответствует нашим ACL
# на уровне драйвера (native mode) или программно (skb mode)

xdp-loader load eth0 ./drop_malicious_traffic.o --mode native

# 3. Мониторим статистику прохождения пакетов через eBPF-карты
bpftool map dump name xdp_stats_map

# Пример простейшего правила для xdp-filter (современная замена многим задачам iptables)
xdp-filter load eth0 -p ipv6 --ip 2001:db8:dead:beef::/64 -a drop

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

Экономия ресурсов CPU. Пока

nftables

тратит циклы на разбор каждого заголовка, XDP просто «срезает» ненужное на входе. Это единственный способ держать аптайм, когда на твой ARM-кластер прилетает «привет» от ботнета в пару терабит.

#linux #xdp #ebpf #networking #highload #admin_future

🐧 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

🐧 Linux: SCHED_EXT — BPF-планировщик процессов, который меняет правила игры

Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.

Почему это важно для нас, а не только для датацентров?

Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.

Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.

Практика — запускаем готовый планировщик на продакшн-хосте:

# Устанавливаем пакет с готовыми BPF-планировщиками
# Fedora / RHEL 10:
dnf install scx-scheds

# Ubuntu 26.04 (из репозитория):
apt install scx-scheds

# Проверяем статус SCHED_EXT в ядре
cat /sys/kernel/sched_ext/state
# disabled — нет активного планировщика, ядро использует CFS

# Запускаем scx_lavd — оптимизирован для latency-чувствительных нагрузок
# (хорошо для баз данных, веб-серверов, очередей)
sudo scx_lavd --performance &

# Проверяем что планировщик активен
cat /sys/kernel/sched_ext/state     # -> enabled
cat /sys/kernel/sched_ext/root/ops  # -> lavd

# Смотрим статистику планировщика в реальном времени
sudo scx_lavd --performance --stats 2

# Для тонкой настройки — scx_layered позволяет создавать слои приоритетов
# Например: критические сервисы в Layer 0, фоновые задачи в Layer 1
sudo scx_layered - << 'EOF'
[
  {
    "name": "critical",
    "matches": [["CgroupPrefix", "system.slice/nginx"]],
    "kind": {"Confined": {"cpus_pct": 60, "util_range": [0.8, 0.9]}}
  },
  {
    "name": "background",
    "matches": [["CgroupPrefix", ""]],
    "kind": {"Confined": {"cpus_pct": 40, "util_range": [0.1, 0.5]}}
  }
]
EOF

# Остановить планировщик — просто Ctrl+C или killall scx_lavd
# Система МГНОВЕННО падает обратно на CFS, никакого даунтайма

Зачем это нужно:
BPF-планировщики можно обновлять без перезагрузки сервера — критически важно для датацентра с сотнями тысяч машин, где rolling reboot занимает недели. Но и для нашего парка из 50 серверов — возможность изолировать приоритет nginx от фоновых cronjob без правки ядра и перезагрузки стоит потраченного часа на изучение.

Итог: CFS — это справедливость для всех. SCHED_EXT — это справедливость там, где тебе нужно. Разница примерно как между светофором и круговым движением: второе умнее, но требует понимания.

#linux #ebpf #sched_ext #performance #kernel #sysadmin #admin_future

🐧 Linux: Cilium без kube-proxy — eBPF как замена iptables в Kubernetes

Коллеги, если у вас Kubernetes и kube-proxy на iptables — вы работаете с инструментом 2001 года. Не метафорически, буквально.

Проблема простая: iptables не был спроектирован для динамических сред. При каждом изменении Service или Endpoint правила перезаписываются целиком — на кластере из 500+ сервисов это создаёт заметную задержку и нагрузку на CPU.

Cilium в режиме kube-proxy replacement решает это через eBPF: таблицы маршрутизации хранятся в BPF maps, обновляются атомарно и обрабатываются прямо в ядре без userspace-прыжков.

# Устанавливаем Cilium с отключённым kube-proxy (k3s / kubeadm)
# При инициализации кластера убираем kube-proxy:
kubeadm init --skip-phases=addon/kube-proxy

# Устанавливаем Cilium через Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true

# Проверяем что kube-proxy replacement активен
cilium status --verbose | grep -i "kube-proxy"
# KubeProxyReplacement: True

# Смотрим BPF-таблицы сервисов напрямую
cilium service list
cilium bpf lb list

# Мониторинг сетевых событий в реальном времени
cilium monitor --type drop

Зачем это нужно:
Cilium с eBPF даёт встроенную наблюдаемость L3/L4/L7 без sidecar-контейнеров, встроенный network policy без overhead iptables, и Hubble — визуализацию трафика между подами в реальном времени. Для кластеров от 50 нод разница в latency ощутима.

Итог: iptables в Kubernetes — это как держать Zabbix 2.0 вместо Prometheus. Работает, но не для 2026 года.

#linux #kubernetes #ebpf #cilium #networking #sysadmin #admin_future