SLO-мониторинг с node_exporter и blackbox_exporter: latency, доступность и error budget

Когда мониторинг сводится к «CPU > 90% — паникуем», он почти неизбежно превращается в шум: алерты есть, ясности нет. SLO-подход делает обратное: сначала фиксируем, что для пользователя является «нормально» (доступность, задержка, корректность ответа), а уже потом выбираем метрики и алерты. Ниже — практичный каркас SLO-мониторинга на Prometheus с двумя экспортерами: node_exporter (состояние хоста) и blackbox_exporter (проверки «снаружи»), плюс расчёт error budget и slo alerts через burn rate.

Что именно мониторим по SLO: SLI, SLO и error budget

SLI (Service Level Indicator) — измеримый индикатор качества сервиса. Примеры: доля успешных HTTP-ответов, доля успешных внешних проверок, доля запросов быстрее заданного порога.

SLO (Service Level Objective) — целевое значение SLI на окне времени. Например: «99.9% успешных проверок за 30 дней» или «99% проверок быстрее 300 мс за 7 дней».

Error budget — «запас ошибок», допустимый при выбранном SLO. Если SLO = 99.9% за 30 дней, бюджет ошибок = 0.1% (0.001) от измерений в этом окне. Удобнее всего думать о бюджете как об управляемом ресурсе: пока бюджет есть — релизы и изменения можно делать смелее; если бюджет стремительно сгорает — стоит притормозить и заняться стабильностью.

Смысл SLO — алертить не «симптомы инфраструктуры», а риск ухудшения пользовательского опыта, причём с учётом окна времени, а не по единичным всплескам.

Роли node_exporter и blackbox_exporter: почему нужны оба

node_exporter — это «внутренний» взгляд: CPU, load, RAM, диски, сеть, файловые системы. Он помогает объяснить, почему сервис деградирует, но сам по себе редко является SLI: пользователю не важно, какой у вас load, ему важно, что сайт отвечает медленно или падает.

blackbox_exporter — «внешний» взгляд: HTTP/TCP/ICMP проверки, TLS, коды ответа, тайминги DNS/Connect/TTFB, редиректы. Это хороший источник SLI для доступности и «наружной» задержки.

Практичный паттерн:

• SLI берём из blackbox_exporter (доступность и пороговая задержка).
• Диагностика — из node_exporter (ресурсы, I/O, сеть) плюс метрики приложения, если они есть.
• SLO alerts строим по burn rate (скорость «сжигания» error budget), а не по единичным падениям.

Если вам нужен быстрый старт на отдельной машине под мониторинг, чаще всего удобнее взять VDS и держать Prometheus/Alertmanager/Grafana там же, а exporters на серверах приложений закрыть в приватной сети.

Быстрый старт: установка exporters на Linux (systemd)

Ниже — «в лоб» пример через systemd (подойдёт для VM/VDS). В проде обычно добавляют ограничения systemd (CapabilityBoundingSet, ProtectSystem), firewall и отдельные подсети под мониторинг, но базовый каркас такой.

node_exporter

useradd --no-create-home --shell /usr/sbin/nologin node_exporter
wget -O /tmp/node_exporter.tar.gz https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar -C /tmp -xzf /tmp/node_exporter.tar.gz
install -m 0755 /tmp/node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/node_exporter
chown node_exporter:node_exporter /usr/local/bin/node_exporter

cat > /etc/systemd/system/node_exporter.service << 'EOF'
[Unit]
Description=Prometheus Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter --web.listen-address=127.0.0.1:9100
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now node_exporter
systemctl status node_exporter

Если Prometheus стоит на другом сервере, вместо 127.0.0.1 используйте приватный адрес и ограничьте доступ firewall. В публичный интернет порты exporters обычно не открывают.

blackbox_exporter

useradd --no-create-home --shell /usr/sbin/nologin blackbox_exporter
wget -O /tmp/blackbox_exporter.tar.gz https://github.com/prometheus/blackbox_exporter/releases/download/v0.25.0/blackbox_exporter-0.25.0.linux-amd64.tar.gz
tar -C /tmp -xzf /tmp/blackbox_exporter.tar.gz
install -m 0755 /tmp/blackbox_exporter-0.25.0.linux-amd64/blackbox_exporter /usr/local/bin/blackbox_exporter
chown blackbox_exporter:blackbox_exporter /usr/local/bin/blackbox_exporter

mkdir -p /etc/blackbox_exporter
cat > /etc/blackbox_exporter/blackbox.yml << 'EOF'
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      method: GET
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      preferred_ip_protocol: "ip4"
      follow_redirects: true
      fail_if_ssl: false
      fail_if_not_ssl: false
      tls_config:
        insecure_skip_verify: false

  http_2xx_tls:
    prober: http
    timeout: 5s
    http:
      method: GET
      follow_redirects: true
      fail_if_not_ssl: true
      preferred_ip_protocol: "ip4"

  tcp_connect:
    prober: tcp
    timeout: 3s

  icmp:
    prober: icmp
    timeout: 2s
EOF
chown -R blackbox_exporter:blackbox_exporter /etc/blackbox_exporter

cat > /etc/systemd/system/blackbox_exporter.service << 'EOF'
[Unit]
Description=Prometheus Blackbox Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=blackbox_exporter
Group=blackbox_exporter
Type=simple
ExecStart=/usr/local/bin/blackbox_exporter --config.file=/etc/blackbox_exporter/blackbox.yml --web.listen-address=127.0.0.1:9115
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now blackbox_exporter
systemctl status blackbox_exporter

Prometheus: как правильно «скрапить» blackbox и node_exporter

Ключевая особенность blackbox_exporter: Prometheus скрапит не цель напрямую, а exporter, передавая цель параметром target. Это позволяет держать одну точку скрапа (exporter) и список проверяемых endpoint.

Пример prometheus.yml (фрагменты)

scrape_configs:
  - job_name: node
    static_configs:
      - targets:
          - 10.0.0.10:9100
          - 10.0.0.11:9100

  - job_name: blackbox_http
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - example.com
          - example.com/healthz
          - api.example.com/ready
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 10.0.0.20:9115

  - job_name: blackbox_tcp
    metrics_path: /probe
    params:
      module: [tcp_connect]
    static_configs:
      - targets:
          - 10.0.0.10:443
          - 10.0.0.10:5432
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 10.0.0.20:9115

Где 10.0.0.20:9115 — адрес сервера, на котором запущен blackbox_exporter (часто это отдельная «monitoring» VM). Для HTTP-целей можно указывать домены без схемы, но для контроля TLS-условий удобнее явно задавать URL, а модуль подбирать под задачу.

Если хотите глубже разобрать модули и relabeling под HTTP/TCP/ICMP, пригодится отдельный разбор: как настроить blackbox_exporter для HTTP/TCP/ICMP проверок.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Latency monitoring через blackbox_exporter: какие метрики реально полезны

Частая ошибка в latency monitoring — алертить по одному числу probe_duration_seconds, не понимая, где именно потратилось время. У blackbox есть разложение по фазам:

• probe_dns_lookup_time_seconds — DNS.
• probe_tcp_connect_duration_seconds — TCP connect.
• probe_tls_handshake_duration_seconds — TLS handshake.
• probe_http_duration_seconds с label phase — детали HTTP.
• probe_duration_seconds — суммарное время проверки.

Практика: в дашборде держите графики по фазам (часто удобно как stacked), а алерт (если он действительно нужен) — по суммарной задержке или по метрикам приложения/ingress. Blackbox измеряет «снаружи» и хорошо ловит сетевые деградации, проблемы DNS, TLS и маршрутизации.

SLO на доступность: считаем SLI и error budget по probe_success

Для HTTP/TCP/ICMP blackbox отдаёт бинарный результат: probe_success (1 — успех, 0 — провал). Это удобная основа для SLI доступности.

SLI: доля успешных проверок за окно

Для окна 30 дней (или любого другого) можно считать так:

avg_over_time(probe_success{job="blackbox_http",instance="example.com"}[30d])

Если метрика скрапится раз в 15 секунд и цель стабильна, avg_over_time даст долю успехов за период. Для SLO 99.9% условие выглядит как «avg >= 0.999».

Error budget: сколько уже «сожгли»

Если SLO = 99.9% на 30 дней, то допустимый процент ошибок 0.1% (0.001). «Потраченная доля бюджета» выражается как:

(1 - avg_over_time(probe_success{job="blackbox_http",instance="example.com"}[30d])) / 0.001

• 0.0 — ошибок не было.
• 1.0 — бюджет исчерпан.
• 2.0 — бюджет превышен вдвое (SLO уже не выполняется на окне).

SLO alerts по burn rate: меньше шума, больше смысла

Классические алерты вида «endpoint down 1 минуту» бывают полезны, но часто создают пейджинг из-за кратковременных сетевых проблем. В SLO-мире обычно алертят скорость сжигания бюджета (burn rate): насколько быстро вы идёте к нарушению SLO, если текущая ситуация сохранится.

Практичный шаблон — multi-window, multi-burn-rate: быстрый алерт на «горит прямо сейчас» и медленный на «плохая тенденция».

Пример: 99.9% за 30 дней (бюджет 0.1%)

Ниже пример правил в стиле burn rate. Это не «единственно верно», но даёт рабочую основу для небольшого продакшена.

groups:
  - name: slo-blackbox
    rules:
      - alert: SLOAvailabilityBurnRateFast
        expr: |
          (
            (1 - avg_over_time(probe_success{job="blackbox_http",instance="example.com"}[5m]))
            /
            0.001
          ) > 14
          and
          (
            (1 - avg_over_time(probe_success{job="blackbox_http",instance="example.com"}[1h]))
            /
            0.001
          ) > 14
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "SLO burn rate high (fast) for example.com"
          description: "Error budget burn rate > 14x on 5m and 1h windows. High risk of SLO violation."

      - alert: SLOAvailabilityBurnRateSlow
        expr: |
          (
            (1 - avg_over_time(probe_success{job="blackbox_http",instance="example.com"}[30m]))
            /
            0.001
          ) > 6
          and
          (
            (1 - avg_over_time(probe_success{job="blackbox_http",instance="example.com"}[6h]))
            /
            0.001
          ) > 6
        for: 10m
        labels:
          severity: ticket
        annotations:
          summary: "SLO burn rate elevated (slow) for example.com"
          description: "Error budget burn rate > 6x on 30m and 6h windows. Investigate trend before it becomes an incident."

Почему два окна в одном алерте: короткое ловит резкий инцидент, длинное фильтрует случайный шум. Это ядро «правильных» slo alerts.

После того как burn rate алерты заработают, логичный следующий шаг — навести порядок в маршрутизации, шаблонах и тишинах. См. практику: роутинг и silence в Alertmanager без хаоса.

SLO по задержке: что реально можно сделать с blackbox

С задержкой сложнее, потому что blackbox измеряет время отдельных проверок, а не распределение реальных запросов. Но как «наружный термометр» он полезен: ловит деградации DNS, TLS, сети и edge.

Если вам нужен SLO формата «p95 < 300 ms», корректнее брать p95 из метрик приложения/ingress. Но можно построить «пороговый SLI» из blackbox: доля проверок, уложившихся в N секунд.

SLI: доля быстрых ответов

Например, SLO: «99% проверок быстрее 0.3s за 7 дней». Тогда SLI:

avg_over_time((probe_duration_seconds{job="blackbox_http",instance="example.com"} <= 0.3)[7d])

Это булевое сравнение, которое превращается в 0/1, и среднее даст долю успешных по задержке проверок. Дальше — тот же принцип error budget и burn rate, только бюджет для latency-SLO будет 1% (0.01), если цель 99%.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Как связать SLO и node_exporter: диагностика после срабатывания

Когда SLO-алерт сработал, следующий шаг — понять, что именно деградировало: сеть, диск, CPU throttling, память, файловая система. Тут и нужен node_exporter.

Минимальный набор графиков/проверок, который реально экономит время:

• CPU: rate(node_cpu_seconds_total{mode="iowait"}[5m]) и rate(node_cpu_seconds_total{mode="steal"}[5m]) (steal часто важен на виртуализации).
• Диск: rate(node_disk_read_time_seconds_total[5m]), rate(node_disk_write_time_seconds_total[5m]), плюс очередь/latency (зависит от устройства и набора метрик).
• Файловые системы: node_filesystem_avail_bytes и node_filesystem_files_free (inodes).
• Сеть: rate(node_network_receive_bytes_total[5m]), а также drops/errors (по интерфейсу).

Важно: node_exporter — не про SLO напрямую, а про быстрый ответ на вопрос «что проверить в первую минуту инцидента».

Практика: как выбирать окна, цели и пороги, чтобы мониторинг не мешал

• Окно SLO: 30 дней для доступности — удобный стандарт; 7 дней — для более динамичных сервисов.
• Период скрапа: 15–30 секунд для blackbox обычно достаточно. Слишком частые проверки могут сами стать нагрузкой.
• Разделяйте цели: /healthz для «жив ли процесс», /ready для «готов обслуживать», и отдельная проверка «главной страницы» как прокси реального UX.
• Не делайте latency-SLO из blackbox «истиной»: используйте как индикатор сети/инфраструктуры; для пользовательской задержки лучше метрики приложения.
• Burn rate вместо “down”: пейджинг — только по burn rate fast, тикеты — по burn rate slow.

Типовые ошибки и как их избежать

1) Один exporter вместо двух

Если есть только node_exporter — вы видите железо, но не видите пользователя. Если есть только blackbox — вы видите симптомы, но «внутри» темно. В паре они закрывают и SLI, и диагностику.

2) Проверки «не тем маршрутом»

Если blackbox ходит на бэкенд минуя балансер/прокси — вы мониторите не тот путь, которым ходят пользователи. Если проверяете только «главную», можно пропустить деградацию API. Делайте несколько целей на разные пользовательские сценарии.

3) Пейджинг на каждую минуту простоя

Единичные «down на 1 минуту» — хороший сигнал, но плохой пейджер. Пейджинг должен означать риск SLO/бюджета, иначе команда выгорает и начинает игнорировать уведомления.

Минимальный чеклист внедрения за вечер

1. Поднять Prometheus, Alertmanager и Grafana (или использовать уже имеющиеся).
2. Поставить node_exporter на все узлы.
3. Поставить blackbox_exporter на monitoring-узел и добавить HTTP/TCP проверки.
4. Определить один SLO на доступность (например, 99.9%/30d) и один на задержку (например, 99% < 300 мс/7d как индикатор).
5. Включить burn rate алерты (fast/slow) и проверить на тестовой цели.
6. Собрать дашборд: фазы blackbox + ключевые графики node_exporter.

Итог

node_exporter и blackbox_exporter — одна из самых практичных связок для небольшого продакшена: первый объясняет состояние узла, второй показывает, что видит клиент. Добавив SLO-логику, burn rate алерты и расчёт error budget, вы получаете мониторинг, который помогает принимать решения: когда пейджить, когда заводить тикет, а когда спокойно выкатывать изменения.

А если публичные endpoint и TLS для вас критичны (магазин, API, личный кабинет), держите сертификаты под контролем: автоматизация важна, но и качество цепочки/совместимость тоже. При необходимости можно оформить SSL-сертификаты для продакшен-доменов и отдельно мониторить срок действия и ошибки TLS через blackbox.