Blackbox‑мониторинг сайтов: проверки HTTP/TCP/ICMP и алерты в Prometheus

Blackbox‑мониторинг — это проверки доступности сервисов со стороны «пользователя». В отличие от whitebox‑метрик (ресурсы, внутренние счётчики), blackbox отвечает на вопросы: «Отдаёт ли сайт 2xx по HTTPS?», «Открыт ли порт и есть ли баннер?», «Доступен ли хост по ICMP?», «Не заканчивается ли срок действия SSL‑сертификата?». Такой контур позволяет поймать проблемы, которые не видны изнутри, — ошибки DNS, сбои TLS‑рукопожатия, перегрузку балансировщика, блокировку межсетевыми правилами и многое другое.

Архитектура решения

Базовая схема проста: Prometheus делает scrape Blackbox Exporter, передавая целевой target и нужный module (HTTP/TCP/ICMP). Экспортёр выполняет пробу и отдаёт метрики: probe_success, probe_duration_seconds, фазовые тайминги (resolve, connect, tls, processing, transfer), а для HTTPS — ещё и probe_ssl_earliest_cert_expiry. Alertmanager получает алерты из Prometheus и маршрутизирует уведомления.

Идеально, когда blackbox‑пробы идут из той же сети, откуда к вам приходит реальный трафик. Так вы ловите сетевые и DNS‑проблемы, которые могут быть невидимы изнутри инфраструктуры.

Для развёртывания экспортёра подойдёт отдельный узел. Если у вас ещё нет подходящего сервера, поднимите его на VDS, чтобы изолировать мониторинг и избежать влияния приложений.

Установка и запуск Blackbox Exporter

Развернуть экспортёр можно как бинарём под systemd. Пример минимальной процедуры (версию подставьте актуальную для вашей среды):

# Создаём пользователя без shell
useradd --system --no-create-home --shell /usr/sbin/nologin blackbox

# Каталоги и права
mkdir -p /etc/blackbox
mkdir -p /var/lib/blackbox
chown -R blackbox:blackbox /etc/blackbox /var/lib/blackbox

# Скопируйте бинарь в /usr/local/bin/blackbox_exporter
# Дайте права
chown root:root /usr/local/bin/blackbox_exporter
chmod 0755 /usr/local/bin/blackbox_exporter

# Для ICMP‑проб экспортёру нужен CAP_NET_RAW
setcap cap_net_raw+ep /usr/local/bin/blackbox_exporter

Создадим unit‑файл systemd:

# /etc/systemd/system/blackbox-exporter.service
[Unit]
Description=Prometheus Blackbox Exporter
After=network-online.target
Wants=network-online.target

[Service]
User=blackbox
Group=blackbox
ExecStart=/usr/local/bin/blackbox_exporter --config.file=/etc/blackbox/blackbox.yml --web.listen-address=:9115
Restart=always
RestartSec=2
AmbientCapabilities=CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_RAW
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Запускаем и проверяем:

systemctl daemon-reload
systemctl enable --now blackbox-exporter
systemctl status blackbox-exporter

Конфигурация модулей Blackbox Exporter

Файл /etc/blackbox/blackbox.yml описывает модули проб: HTTP, TCP, ICMP и их параметры. Начнём с трёх самых востребованных:

modules:
  http_2xx:
    prober: http
    timeout: 10s
    http:
      method: GET
      valid_http_versions: ["HTTP/1.1", "HTTP/2"]
      valid_status_codes: [200, 201, 202, 204, 301, 302, 304]
      preferred_ip_protocol: ip4
      no_follow_redirects: false
      tls_config:
        insecure_skip_verify: false
      headers:
        Host: example.com
        User-Agent: BlackboxProber/1.0
      fail_if_body_not_matches:
        - "<html"
  http_post_json_health:
    prober: http
    timeout: 5s
    http:
      method: POST
      headers:
        Content-Type: application/json
      body: '{"ping":"ok"}'
      valid_status_codes: [200]
      fail_if_body_not_matches:
        - "status\":\"ok\""
  tcp_connect:
    prober: tcp
    timeout: 5s
    tcp:
      preferred_ip_protocol: ip4
      tls: false
  tcp_banner_smtp:
    prober: tcp
    timeout: 5s
    tcp:
      preferred_ip_protocol: ip4
      query_response:
        - expect: "^220"
  icmp:
    prober: icmp
    timeout: 2s
    icmp:
      preferred_ip_protocol: ip4

Комментарии к настройкам:

• http_2xx — классическая проверка сайта по HTTPS; следит за кодами 2xx/3xx, проверяет наличие HTML в теле и не игнорирует TLS‑ошибки.
• http_post_json_health — удобно для REST‑health‑эндпоинтов, когда требуется POST и валидация тела.
• tcp_connect — проверка, что порт принимает соединение (например, 443 на балансировщике, 22 на админ‑узле, 5432 на БД, если это требуется вашей политикой мониторинга).
• tcp_banner_smtp — контролирует баннер SMTP, ожидая статус линии, тем самым отлавливая некорректные проксирования и блокировки.
• icmp — классический ping; требует CAP_NET_RAW.

Если ваш сайт работает на виртуальном хостинге, а экспортер крутится вне площадки (например, на VDS), обязательно укажите правильный Host/SNI в HTTP‑модуле, иначе получите ошибки сертификата.

Настраиваем Prometheus: scrape и relabeling

Добавим в prometheus.yml три scrape‑задачи для разных модулей. Ключевая идея: Prometheus обращается к Blackbox Exporter по адресу экспортёра, а целевой хост передаёт в параметре target через relabeling.

scrape_configs:
  - job_name: 'blackbox_http'
    metrics_path: /probe
    scrape_interval: 30s
    scrape_timeout: 15s
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://example.com
          - https://status.example.net/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

  - job_name: 'blackbox_tcp'
    metrics_path: /probe
    scrape_interval: 30s
    scrape_timeout: 10s
    params:
      module: [tcp_connect]
    static_configs:
      - targets:
          - 203.0.113.10:443
          - mail.example.net:25
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

  - job_name: 'blackbox_icmp'
    metrics_path: /probe
    scrape_interval: 30s
    scrape_timeout: 5s
    params:
      module: [icmp]
    static_configs:
      - targets:
          - 198.51.100.5
          - gw.example.org
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Обратите внимание на таймауты: scrape_timeout должен быть немного больше, чем timeout модуля в Blackbox. Так Prometheus не обрежет ответ раньше времени.

Динамические цели через file_sd

Если список целей меняется автоматически (кубер‑кластеры, динамическая инфраструктура), используйте file_sd_configs. Пример конфигурации для HTTP‑модуля:

scrape_configs:
  - job_name: 'blackbox_http'
    metrics_path: /probe
    scrape_interval: 30s
    scrape_timeout: 15s
    params:
      module: [http_2xx]
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/http_endpoints.yml
        refresh_interval: 30s
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

Файл целей:

# /etc/prometheus/targets/http_endpoints.yml
- labels:
    team: web
    env: prod
  targets:
    - https://shop.example.com
    - https://api.example.com/health
- labels:
    team: core
    env: staging
  targets:
    - https://staging.example.net

Правила алертов: от доступности до деградации скорости

Ниже показаны практичные правила с антишумовыми окнами. Сглаживайте короткие флаппинги с помощью функций for и агрегации по истории.

groups:
- name: blackbox.alerts
  rules:
  - alert: BlackboxProbeFailed
    expr: avg_over_time(probe_success[5m]) < 0.5
    for: 2m
    labels:
      severity: critical
      team: web
    annotations:
      summary: "Цель недоступна (blackbox)"
      description: "{{ $labels.job }} {{ $labels.instance }}: probe_success падает < 50% за 5m"

  - alert: BlackboxHttpSlowTotal
    expr: avg_over_time(probe_duration_seconds[5m]) > 2
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "HTTP медленный ответ"
      description: "{{ $labels.instance }}: средняя длительность пробы > 2s за 5m"

  - alert: BlackboxHttpSlowTLS
    expr: avg_over_time(probe_http_duration_seconds{phase="tls"}[5m]) > 0.5
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "TLS рукопожатие медленное"
      description: "{{ $labels.instance }}: TLS phase > 0.5s (5m) — возможны проблемы сети/сертификации"

  - alert: BlackboxHttpBadStatus
    expr: (probe_success == 1) and (probe_http_status_code >= 500)
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "HTTP 5xx на цели"
      description: "{{ $labels.instance }}: код {{ $value }}"

  - alert: BlackboxSSLCertExpiringSoon
    expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 14
    for: 30m
    labels:
      severity: warning
    annotations:
      summary: "SSL сертификат истекает"
      description: "{{ $labels.instance }}: осталось < 14 дней до истечения сертификата"

  - alert: BlackboxIcmpUnreachable
    expr: avg_over_time(probe_success{job="blackbox_icmp"}[5m]) == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "ICMP недоступен"
      description: "{{ $labels.instance }} не отвечает на ping (5m)"

Объяснение логики:

• BlackboxProbeFailed сглаживает одиночные таймауты (берём среднее за 5 минут).
• BlackboxHttpSlowTotal и BlackboxHttpSlowTLS помогают отличить проблемы приложения (фаза processing) от сетевых/TLS‑проблем (фаза tls или connect).
• BlackboxHttpBadStatus срабатывает только если пробы успешны, но код ответа 5xx.
• BlackboxSSLCertExpiringSoon — раннее предупреждение, чтобы успеть перевыпустить сертификат. Если вы управляете выпуском, используйте надёжные SSL-сертификаты и автоматизацию перевыпуска. Подробности — в материале «HTTPS, Certbot и HSTS».
• BlackboxIcmpUnreachable — контроль доступности на уровне сети.

Отладка проб

Иногда важно быстро понять, что именно ломается: DNS‑резолв, TCP‑коннект, TLS или приложение. Полезные шаги:

• Локальный вызов пробы к экспортёру с нужным модулем и целью, чтобы увидеть сырой ответ и тайминги.
• Сверка фазовых метрик probe_http_duration_seconds по лейблу phase: resolve, connect, tls, processing, transfer.
• Проверка прав CAP_NET_RAW для ICMP.

# Проверка HTTP модуля руками
curl -s 'http://127.0.0.1:9115/probe?target=https://example.com&module=http_2xx' | grep -E '^probe_|^http_'

# Проверка TCP порта
curl -s 'http://127.0.0.1:9115/probe?target=203.0.113.10:443&module=tcp_connect' | grep -E '^probe_'

# Проверка ICMP
curl -s 'http://127.0.0.1:9115/probe?target=198.51.100.5&module=icmp' | grep -E '^probe_'

Если probe_success равен 0, смотрите метрики длительности по фазам — это быстро подсказывает зону проблемы. Например, для TLS‑ошибок probe_http_ttfb_seconds не вырастет, зато probe_http_duration_seconds{phase="tls"} будет заметен.

Лучшие практики эксплуатации

• Разделяйте задачи: отдельно job для HTTP, TCP и ICMP. Это упрощает фильтрацию и алертинг.
• Добавляйте лейблы team, env, service ещё на этапе static_configs или file_sd, чтобы Alertmanager знал, куда слать уведомления.
• Важные цели проверяйте каждые 15–30 секунд, вторичные — раз в минуту и реже.
• Выносите проверку из нескольких точек (например, два экспортёра в разных дата‑центрах) и включайте кворум в алертах: тревогой считаем, когда минимум две площадки видят проблему.
• Следите за лимитами: не перегружайте слабые площадки агрессивными интервалами и большим числом целей; используйте несколько инстансов экспортёра.
• Для HTTPS всегда оставляйте insecure_skip_verify: false и настраивайте headers.Host при проверке по IP с SNI/Host‑заголовком, иначе получите ложные срабатывания по сертификату.
• Синхронизируйте timeout модуля и scrape_timeout Prometheus с запасом в 1–2 секунды.
• Не смешивайте blackbox и whitebox алерты по одному сервису в одну группу — разделяйте каналы и приоритеты, чтобы ускорить triage.

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

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Расширенные HTTP‑кейсы

Кроме простого GET‑пинга, blackbox позволяет:

• Проверять POST и другие методы (как в примере http_post_json_health), валидировать тело по регулярным выражениям.
• Проверять специфичные заголовки: ответ по Cache-Control, наличие нужной версии API в X-‑заголовке.
• Запретить редиректы (no_follow_redirects: true), если вам важно отлавливать петли 3xx на балансировщике. Про миграции и редиректы — в статье «301, HSTS и SSL при миграции домена».
• Жёстко указать допустимые статусы (valid_status_codes), если в норме у вас 204 No Content или 301 на /.

Чтобы не хранить секреты в конфиге экспортёра, обычно проверяют публичные health‑эндпоинты или используют фильтрацию по заголовкам без секретов. Для приватных проверок предпочтительнее whitebox‑метрики или промежуточные внутренние health‑плагины.

TCP‑пробы: не только «порт открыт»

TCP‑модуль может отправлять и ожидать строки (баннеры). Это полезно для SMTP/IMAP, Redis, Memcached, собственных TCP‑демонов. Вы можете проверить, что балансировщик действительно проксирует на правильный бэкенд, а не отдаёт заглушку.

Расширенный модуль с баннером уже показан как tcp_banner_smtp. Аналогично можно ожидать «+PONG» от Redis при отправке PING\r\n и выполнить fail, если в ответе нет ожидаемого шаблона.

ICMP‑пробы и безопасность

ICMP‑пробы удобны для быстрого понимания сетевой доступности. На некоторых узлах ICMP может быть закрыт политиками безопасности — это нормально. В таком случае используйте TCP‑пробы на известный порт (часто 443), чтобы получить эквивалентный индикатор доступности на уровне L4.

Не забудьте про права CAP_NET_RAW и о том, что запуск под systemd с AmbientCapabilities должен отражать это требование.

Снижение шума и SLO

Основной источник шума в blackbox — кратковременные сетевые всплески и GC/рестарты приложений. Рецепты:

• Сглаживайте probe_success функциями avg_over_time или max_over_time, добавляйте for в правила.
• Для деградации скорости задайте пороги отдельно по фазам. Высокий resolve — проблемы с DNS. Высокий connect — сеть/балансировщик. Высокий processing — приложение или БД.
• Учитывайте часы пик: меняйте пороги по env/team/service либо используйте разные правила для prod/stage.

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

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

Подробнее

Набор готовых запросов для диагностики

Ниже несколько полезных промкверей для ручной диагностики в консоли Prometheus:

• Самые медленные цели за 15 минут: topk(10, avg_over_time(probe_duration_seconds[15m])).
• Список целей с TLS > 300 мс: sort_desc(avg_over_time(probe_http_duration_seconds{phase="tls"}[15m])).
• Цели с частыми 5xx: sum by (instance) (increase(probe_http_status_code{job="blackbox_http", code="5xx"}[1h])) — или фильтр по probe_http_status_code >= 500, если нет отдельной лейблизации кодов.

Частые ошибки и как их избежать

• Не совпадают таймауты. scrape_timeout меньше, чем модульный timeout — Prometheus обрезает пробу. Держите запас 1–2 секунды.
• Проверка по IP без Host/SNI. Для виртуального хостинга и TLS укажите headers.Host и корректный SNI, иначе будет «не тот» сертификат.
• Алерты дублируются. Если у вас несколько площадок, применяйте кворум в правилах (например, через count_values по лейблу площадки) либо гистерезис.
• ICMP не работает. Проверьте CAP_NET_RAW и политику файервола. При невозможности — используйте TCP‑пробу.
• Большой объём целей в одном инстансе. Разделите по нескольким экспортёрам или распределяйте цели через сервис‑дискавери, чтобы не создавать «бутылочное горлышко».

Итоги

Связка Prometheus + Blackbox Exporter закрывает ключевую потребность SRE и DevOps: проверять доступность сервисов ВНЕ их внутренней логики. HTTP/TCP/ICMP‑пробы помогают увидеть проблемы с DNS, сетью, балансировщиками и TLS, а грамотные алерты по probe_success, фазовым задержкам и сроку SSL позволяют реагировать до того, как инцидент поедет в прод. Начните с трёх модулей из статьи, добавьте relabeling и file_sd для динамики, прикрутите антишумовые окна — и у вас появится надёжный контур доступности, который легко расширять под новые сервисы.

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

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее