Гибридная стратегия метрик: Prometheus + Grafana + eBPF

Если ты когда-нибудь мониторил сервера и ловил себя на мысли: «Чёрт, как бы увидеть чуть больше, чем просто CPU и RAM?», то это статья для тебя. Сегодня разбираем гибридную стратегию метрик — как собрать в кучу Prometheus, Grafana и eBPF, чтобы не только видеть красивые графики, но и реально понимать, что творится у тебя в системе на уровне ядра. На выходе — не просто дашборд, а почти рентген твоего железа. Разберёмся, зачем это вообще нужно, как быстро всё поднять (ну, почти быстро), какие подводные камни встретишь и почему такой стек — это будущее мониторинга.

Зачем вообще заморачиваться с гибридной стратегией метрик?

• Стандартный мониторинг уже не тянет — банальные node_exporter/telegraf не показывают глубину. Видишь, что нагрузка выросла, а кто виноват — неясно.
• eBPF — это твой швейцарский нож для ядра. Он позволяет собирать метрики, которые раньше были доступны только через сложные профайлеры и дебаггеры.
• Prometheus + Grafana — проверенная связка для сбора и визуализации, но с eBPF она выходит на новый уровень.
• Гибридный подход — это когда классические метрики + глубинное ядро = полная картина.

Если у тебя VPS, выделенный сервер или даже десяток контейнеров в облаке — с этим стеком ты будешь знать, что у тебя происходит на уровне системных вызовов, сетевого стека, дисков и даже отдельных процессов.

Проблема: почему стандартные метрики больше не спасают?

Представь: сервер начал тормозить, CPU в потолке, но кто жрёт ресурсы — неясно. Или сеть вдруг стала лагать, а стандартные netstat/iftop ничего не показывают. Вся классика мониторинга (Nagios, Zabbix, даже Prometheus с обычными экспортёрами) даёт только верхушку айсберга. А что внутри? Где эти злосчастные syscalls, какие процессы лезут в сеть, кто жрёт диск? Вот тут и спасает eBPF.

eBPF (extended Berkeley Packet Filter) — это, по сути, способ запускать мини-программы прямо в ядре Linux. Они могут собирать метрики, фильтровать пакеты, отслеживать системные вызовы и т.д. При этом они быстрые и безопасные (ядро не даст им накосячить).

Как это вообще работает?

Архитектура и алгоритмы

• Prometheus — собирает метрики через pull (обычно по HTTP).
• Grafana — рисует красивые графики на основе данных Prometheus.
• eBPF-экспортёры (например, ebpf_exporter или bcc) — запускают eBPF-программы, собирают глубокие метрики и отдают их в Prometheus-совместимом формате.
• В итоге: Prometheus опрашивает eBPF-экспортёр + классические экспортёры (node_exporter и т.п.), Grafana подключается к Prometheus и рисует всё в одном дашборде.

Схематично:

[Сервер]
   |
   |-- node_exporter (cpu, mem, disk, basic net)
   |-- ebpf_exporter (syscalls, net flows, disk I/O, process tracing)
   |
[Prometheus]
   |
[Grafana]

eBPF ловит события ядра, агрегирует их, экспортёр превращает это в метрики, Prometheus собирает, Grafana визуализирует. Всё!

Как быстро и просто всё настроить?

1. Минимальные требования

• Linux ядро 4.9+ (лучше свежее, для eBPF 5.4+ — идеал).
• root-доступ (или sudo).
• Docker (по желанию, всё можно крутить в контейнерах).

2. Установка Prometheus и Grafana

Самый быстрый способ — через Docker Compose. Вот базовый docker-compose.yml:

version: "3"
services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"
  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
volumes:
  prometheus_data:
  grafana_data:

Создай prometheus.yml с такими настройками:

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'ebpf'
    static_configs:
      - targets: ['localhost:9435']

3. Установка node_exporter (классика)

wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz
cd node_exporter-1.7.0.linux-amd64
./node_exporter &

По умолчанию слушает на 9100.

4. Установка eBPF-экспортёра

Рассмотрим ebpf_exporter от Cloudflare. Он умеет собирать метрики по кастомным eBPF-программам.

git clone https://github.com/cloudflare/ebpf_exporter.git
cd ebpf_exporter
make
sudo ./ebpf_exporter --config.file=examples/config.yaml

По умолчанию слушает на 9435.

NB! Если не хочешь компилить из исходников — ищи готовый бинарник под свою систему или используй Docker-образ.

5. Настройка eBPF-метрик

В examples/config.yaml есть куча шаблонов. Например, собирать системные вызовы (syscalls) процессов:

programs:
  - name: syscalls
    metrics:
      - name: syscalls_total
        help: "Number of syscalls"
        type: counter
    code: |
      int kprobe__sys_enter(void *ctx) {
        syscalls_total.inc();
        return 0;
      }

Можно собирать сетевые флоу, задержки, ошибки, I/O, что угодно. Смотри примеры.

6. Подключение Grafana

• Зайди на localhost:3000 (логин/пароль по умолчанию — admin/admin).
• Добавь Prometheus как источник данных (http://localhost:9090).
• Импортируй готовые дашборды (например, Node Exporter Full или кастомные для eBPF).

7. Всё, у тебя гибридный мониторинг!

В одном Grafana-дэшборде можно видеть и стандартные метрики, и глубинные eBPF-метрики: кто делает syscalls, какие процессы грузят диск, кто лезет в сеть и т.д.

Живые примеры: когда гибридная стратегия реально спасает

Положительные кейсы

• Один клиент жаловался на лаги в Docker-кластере. Оказалось, что один контейнер flood-ил syscalls через logrotate. eBPF показал виновника за 5 минут.
• На VPS были непонятные сетевые лаги — выяснилось, что fail2ban сыпал iptables-правила, eBPF подсветил частые обращения к netfilter.

Отрицательные кейсы

• На старых ядрах (до 4.9) eBPF не работает, пришлось срочно обновлять систему.
• Если запускать всё под root, можно случайно дать слишком много прав экспортёрам. Лучше делать отдельного пользователя с нужными капабилити.

Типичные ошибки и мифы

• Миф: eBPF — это только для сетевиков. На деле: он видит всё, что происходит в ядре: процессы, файлы, сеть, syscalls.
• Ошибка: “Поставлю eBPF — и всё сразу заработает”. Не все eBPF-программы стабильны, иногда нужно донастраивать.
• Ошибка новичка: не проверять права и версию ядра. Без поддержки eBPF ничего не заведётся.
• Миф: eBPF — это небезопасно. На деле: ядро фильтрует все программы, не даёт им ломать систему.

Похожие решения и сравнение

Интересные факты и лайфхаки

• eBPF-программы можно писать на C, но есть генераторы на Python (bcc), Go (cilium/ebpf), даже Rust.
• Можно не только мониторить, но и реагировать на события: например, автоматически убивать процессы, которые flood-ят syscalls или лезут в сеть.
• eBPF умеет делать трассировку сетевых пакетов на уровне ядра — идеальный инструмент для анализа DDoS и сложных сетевых багов.
• Можно строить автоматические алерты на eBPF-метриках — например, если какой-то процесс делает слишком много обращений к файловой системе.
• Есть готовые дашборды для Grafana с eBPF-метриками (ищи по тегу ebpf).

Автоматизация и скрипты: новые горизонты

• С помощью eBPF можно автоматизировать профилирование приложений (например, запускать трассировку только при аномалиях).
• Гибридные метрики легко интегрируются в CI/CD пайплайны — можно автоматически мониторить новые релизы, отслеживать регрессии.
• Скрипты на Python или Go могут собирать, анализировать и даже автоматически чинить проблемы на основе eBPF-метрик.
• Можно строить self-healing инфраструктуру: если eBPF-метрика превышает порог — скрипт рестартит сервис или отправляет алерт в Telegram/Slack.

Выводы и рекомендации

• Гибридная стратегия метрик (Prometheus + Grafana + eBPF) — это не просто модный стек, а реально рабочий инструмент для мониторинга серверов любого масштаба.
• С этим стеком ты видишь не только «что», но и «почему» — кто грузит систему, какие процессы аномально себя ведут, где зарыта проблема.
• Подходит для VPS, выделенных серверов, облачных инстансов, Docker-кластеров.
• Требует минимальных знаний Linux, но открывает огромные возможности для автоматизации и глубокого анализа.
• Если хочешь быстро поднять сервер под мониторинг — зацени VPS или выделенный сервер с современным ядром.
• Не бойся экспериментировать — eBPF уже сегодня открывает такие горизонты мониторинга, о которых раньше можно было только мечтать.

Официальные ресурсы и полезные ссылки:

• Prometheus
• Grafana
• ebpf_exporter
• BCC (BPF Compiler Collection)
• eBPF.io
• Cilium eBPF library

Если хочешь не просто мониторить, а реально понимать, что происходит на твоих серверах — пробуй гибридную стратегию метрик. Это не больно, не сложно, зато очень круто!