Проактивный мониторинг отказоустойчивости: раннее обнаружение сбоев с Prometheus и Grafana | AdminWiki
Logo

Проактивный мониторинг отказоустойчивости: раннее обнаружение сбоев с Prometheus и Grafana

21 августа 2026 10 мин. чтения
Содержание статьи

Что такое проактивный мониторинг и почему он важен для отказоустойчивости

Проактивный мониторинг - это система наблюдения за инфраструктурой, которая выявляет признаки деградации до того, как они превратятся в инцидент. Реактивный подход фиксирует уже случившийся отказ: сервис упал, пользователи жалуются, алерт пришёл постфактум. Проактивный подход запускает синтетические проверки каждые 15–30 секунд и сравнивает текущие метрики с базовыми значениями. Отклонение от нормы фиксируется на ранней стадии.

Разница между подходами видна на конкретном сценарии. Реактивный мониторинг сообщит о недоступности API, когда балансировщик уже вернул 502 и часть запросов потеряна. Проактивный мониторинг с Blackbox Exporter заметит рост времени ответа с 120 мс до 800 мс за несколько минут до полного отказа. У администратора появляется окно для вмешательства: перезапустить сервис, расширить пул соединений, откатить релиз.

Преимущества проактивного мониторинга измеримы. Снижение MTTR (среднего времени восстановления) на 40–60% достигается за счёт раннего обнаружения. Уменьшение числа инцидентов, видимых пользователям, напрямую влияет на SLA. Стек Prometheus и Grafana стал стандартом де-факто для таких задач: Prometheus собирает и хранит метрики, Grafana визуализирует их, Blackbox Exporter выполняет синтетические проверки доступности извне.

Если вы уже используете этот стек для мониторинга серверов, статья Стек мониторинга серверов: настройка Prometheus, Grafana и оповещений поможет освежить базовую конфигурацию. Здесь мы идём дальше: настраиваем именно проактивные проверки и пороги алертов.

Обзор стека мониторинга: Prometheus, Grafana и Blackbox Exporter

Каждый компонент стека решает свою задачу. Prometheus - сервер сбора метрик с pull-моделью: он сам опрашивает экспортеры по HTTP, сохраняет данные в локальной time-series базе и выполняет правила алертов на языке PromQL. Grafana подключается к Prometheus как к источнику данных и строит дашборды. Blackbox Exporter - отдельный экспортер, который выполняет проверки доступности: HTTP-запросы, ICMP-пинги, TCP-соединения, DNS-запросы.

Схема взаимодействия выглядит так:

  1. Blackbox Exporter получает запрос от Prometheus с параметрами цели и типа проверки.
  2. Blackbox Exporter выполняет проверку (например, HTTP GET на https://api.example.com/health) и возвращает метрики: up, probe_duration_seconds, probe_http_status_code.
  3. Prometheus сохраняет метрики и оценивает правила алертов.
  4. Alertmanager получает сработавшие алерты, группирует их и отправляет уведомления.
  5. Grafana отображает метрики на дашбордах в реальном времени.

Ключевое отличие Blackbox Exporter от node_exporter: node_exporter собирает метрики внутри сервера (CPU, память, диски), а Blackbox Exporter проверяет сервис снаружи, как это делал бы пользователь. Это критично для отказоустойчивости: внутренние метрики могут быть в норме, пока сетевой доступ или балансировщик уже отказали.

Установка и настройка Prometheus

Для быстрого развёртывания используем Docker. Он даёт воспроизводимость и простоту обновления. Все конфигурации проверены на Prometheus 2.53 и совместимы с версиями 2026 года.

Установка Prometheus с помощью Docker

Создайте файл docker-compose.yml:

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:v2.53.0
    container_name: prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.enable-lifecycle'

volumes:
  prometheus_data:

Параметр --web.enable-lifecycle позволяет перезагружать конфигурацию без остановки контейнера через POST-запрос к /-/reload. Volume prometheus_data сохраняет метрики между перезапусками.

Базовая конфигурация prometheus.yml

Создайте файл prometheus.yml рядом с docker-compose.yml:

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    monitor: 'proactive-monitoring'

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

Раздел global задаёт интервал опроса метрик и оценки алертов. Значение 15 секунд - разумный баланс между оперативностью и нагрузкой. Раздел scrape_configs описывает источники метрик. Первая задача - сам Prometheus, чтобы отслеживать его состояние.

Запустите стек:

docker compose up -d

Проверьте работу через веб-интерфейс на порту 9090. В разделе Status → Targets должна отображаться цель prometheus со статусом UP.

Установка и настройка Grafana

Установка Grafana с помощью Docker

Добавьте сервис в docker-compose.yml:

  grafana:
    image: grafana/grafana:11.1.0
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=change_me_strong_password
    volumes:
      - grafana_data:/var/lib/grafana

Добавьте volume grafana_data в общий список volumes. После запуска Grafana доступна на порту 3000. Смените пароль администратора на стойкий: стандартные учётные данные - первая цель атакующих.

Подключение Grafana к Prometheus

В веб-интерфейсе Grafana перейдите в Configuration → Data Sources → Add data source. Выберите Prometheus. В поле URL укажите http://prometheus:9090, если оба контейнера в одной Docker-сети, или http://localhost:9090, если Grafana запущена на хосте. Нажмите Save & Test. Успешное соединение подтверждает зелёная плашка.

Для быстрого старта импортируйте дашборд Prometheus 2.0 Stats: Dashboards → Import → введите ID 3662. Он показывает состояние самого Prometheus: количество целей, скорость сбора метрик, использование памяти.

Настройка Blackbox Exporter для синтетических проверок

Blackbox Exporter - ключевой компонент проактивного мониторинга. Он выполняет проверки, которые имитируют действия пользователя, и возвращает метрики в формате Prometheus.

Установка Blackbox Exporter

Добавьте сервис в docker-compose.yml:

  blackbox:
    image: prom/blackbox-exporter:v0.25.0
    container_name: blackbox
    restart: unless-stopped
    ports:
      - "9115:9115"
    volumes:
      - ./blackbox.yml:/etc/blackbox_exporter/blackbox.yml
    command:
      - '--config.file=/etc/blackbox_exporter/blackbox.yml'

Порт 9115 - стандартный для Blackbox Exporter. Prometheus будет опрашивать его по этому порту.

Конфигурация модулей проверок

Создайте файл blackbox.yml:

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: [200, 201, 204]
      method: GET
      preferred_ip_protocol: "ip4"

  icmp:
    prober: icmp
    timeout: 5s
    icmp:
      preferred_ip_protocol: "ip4"

  tcp_connect:
    prober: tcp
    timeout: 5s
    tcp:
      preferred_ip_protocol: "ip4"

Модуль http_2xx проверяет HTTP-ответ и считает успешными коды 200, 201, 204. Модуль icmp выполняет ping. Модуль tcp_connect проверяет установку TCP-соединения на указанный порт. Timeout 5 секунд предотвращает зависание проверок.

Интеграция Blackbox Exporter с Prometheus

Добавьте новую задачу в scrape_configs файла prometheus.yml:

  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://admin-wiki.ru
        - https://api.example.com/health
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox:9115

Разберём конфигурацию. metrics_path: /probe указывает Prometheus запрашивать метрики у Blackbox Exporter через эндпоинт /probe. Параметр module задаёт тип проверки. Список targets - проверяемые URL и хосты. Блок relabel_configs перенаправляет адрес цели в параметр target и заменяет адрес опроса на blackbox:9115.

Для проверки TCP-порта добавьте отдельную задачу:

  - job_name: 'blackbox_tcp'
    metrics_path: /probe
    params:
      module: [tcp_connect]
    static_configs:
      - targets:
        - 'db.example.com:5432'
        - 'redis.example.com:6379'
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox:9115

Перезагрузите конфигурацию Prometheus:

curl -X POST http://localhost:9090/-/reload

В Status → Targets появятся новые цели с меткой job="blackbox".

Определение ключевых метрик для отказоустойчивости

Blackbox Exporter возвращает набор метрик для каждой проверки. Три из них критичны для отказоустойчивости: up, probe_duration_seconds, probe_http_status_code.

Метрики доступности и времени ответа

Метрика up принимает значение 1, если проверка успешна, и 0, если нет. Это базовая метрика доступности. Для HTTP-проверок up == 1 означает, что сервис вернул код из списка valid_status_codes в пределах таймаута. Для ICMP - что ping прошёл. Для TCP - что соединение установлено.

Метрика probe_duration_seconds фиксирует время выполнения проверки в секундах. Рост этого значения сигнализирует о деградации: сеть перегружена, сервер медленно обрабатывает запросы, база данных не справляется. Отслеживайте не абсолютное значение, а отклонение от базового. Если среднее время ответа API за неделю - 150 мс, а сейчас стабильно 400 мс, это повод для проверки.

Запрос PromQL для среднего времени ответа за 5 минут:

avg_over_time(probe_duration_seconds{job="blackbox"}[5m])

Запрос для доступности в процентах за час:

avg_over_time(up{job="blackbox"}[1h]) * 100

Метрики ошибок и их анализ

Метрика probe_http_status_code возвращает код HTTP-ответа. Коды 5xx указывают на ошибки сервера, 4xx - на ошибки клиента или неправильную конфигурацию проверки. Настройте алерт на коды 5xx, а коды 4xx используйте для отладки: возможно, изменился URL или требуются аутентификационные заголовки.

Запрос для подсчёта ошибок 5xx за 10 минут:

sum by (instance) (increase(probe_http_status_code{job="blackbox", code=~"5.."}[10m]))

Для более глубокого анализа надёжности сервисов рекомендую изучить статью Мониторинг и алертинг распределённых систем: Prometheus и Grafana для SLA сервисов. Там разобраны health checks, circuit breakers и метрики SLA.

Настройка порогов срабатывания алертов и уведомлений

Создание правил алертов в Prometheus

Создайте файл alerts.yml и подключите его в prometheus.yml:

rule_files:
  - "/etc/prometheus/alerts.yml"

Пример правил алертов:

groups:
  - name: availability
    rules:
      - alert: ServiceDown
        expr: up{job="blackbox"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Сервис {{ $labels.instance }} недоступен"
          description: "Проверка {{ $labels.module }} не прошла в течение 2 минут."

      - alert: HighResponseTime
        expr: probe_duration_seconds{job="blackbox"} > 0.5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Время ответа {{ $labels.instance }} превышает 500 мс"
          description: "Текущее значение: {{ $value }} сек."

      - alert: HighErrorRate
        expr: rate(probe_http_status_code{job="blackbox", code=~"5.."}[5m]) > 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Высокая частота ошибок 5xx на {{ $labels.instance }}"
          description: "Частота ошибок: {{ $value }} ошибок в секунду."

Параметр for задаёт минимальную длительность условия до срабатывания алерта. Для критических алертов 2 минуты - разумный порог: он отсекает кратковременные сетевые флуктуации, но не затягивает реакцию. Для предупреждений используйте 5 минут. Порог 0.5 секунды для времени ответа - отправная точка; подстройте его под базовые значения ваших сервисов.

Настройка Alertmanager для отправки уведомлений

Добавьте Alertmanager в docker-compose.yml:

  alertmanager:
    image: prom/alertmanager:v0.27.0
    container_name: alertmanager
    restart: unless-stopped
    ports:
      - "9093:9093"
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml

Подключите Alertmanager к Prometheus в prometheus.yml:

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

Создайте alertmanager.yml с маршрутизацией в Slack и email:

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-critical'
  routes:
    - match:
        severity: critical
      receiver: 'slack-critical'
    - match:
        severity: warning
      receiver: 'email-warnings'

receivers:
  - name: 'slack-critical'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
        channel: '#alerts-critical'
        title: '[{{ .Status | toUpper }}] {{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}\n{{ end }}'

  - name: 'email-warnings'
    email_configs:
      - to: 'admin@example.com'
        from: 'alertmanager@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'alertmanager@example.com'
        auth_password: 'smtp_password'

Параметр group_by объединяет алерты с одинаковыми метками в одно уведомление. repeat_interval: 4h предотвращает спам: повторное уведомление по активному алерту придёт не раньше чем через 4 часа. Для тестирования отправки используйте веб-интерфейс Alertmanager на порту 9093.

Создание дашбордов в Grafana для визуализации

Основные панели для мониторинга доступности

Создайте новый дашборд: Dashboards → New → Add visualization. Выберите источник Prometheus. Добавьте три панели.

Панель статуса доступности. Тип - Stat. Запрос:

up{job="blackbox"}

Настройте Value mappings: 1 → UP (зелёный), 0 → DOWN (красный). Панель покажет текущий статус каждой цели.

Панель времени ответа. Тип - Time series. Запрос:

probe_duration_seconds{job="blackbox"}

Настройте легенду на отображение метки instance. График покажет динамику времени ответа по всем целям.

Панель ошибок. Тип - Time series. Запрос:

increase(probe_http_status_code{job="blackbox", code=~"5.."}[5m])

Панель отобразит частоту ошибок 5xx за скользящие 5-минутные интервалы.

Настройка переменных и шаблонов

Создайте переменную target: Dashboard settings → Variables → Add variable. Тип - Query. Запрос:

label_values(up{job="blackbox"}, instance)

Теперь в запросах панелей используйте instance="$target". Переменная добавит выпадающий список в верхней части дашборда для фильтрации по конкретной цели. Это удобно при мониторинге десятков сервисов.

Готовые дашборды можно импортировать с Grafana.com. Для Blackbox Exporter используйте ID 7587 - он содержит панели доступности, времени ответа и статус-кодов.

Обеспечение отказоустойчивости самого мониторинга

Система мониторинга, которая сама падает, не выполняет свою функцию. Prometheus в одном экземпляре - единая точка отказа. Если сервер с Prometheus выйдет из строя, вы потеряете и сбор метрик, и алертинг.

Минимальные меры: регулярное резервное копирование данных Prometheus (volume prometheus_data), конфигурационных файлов и дашбордов Grafana. Храните конфигурации в Git - это даст историю изменений и возможность быстрого восстановления.

Для production-окружений рассмотрите запуск двух экземпляров Prometheus с одинаковой конфигурацией. Они работают независимо и собирают одинаковые метрики. Если один падает, второй продолжает алертинг. Для долгосрочного хранения и горизонтального масштабирования используйте Thanos или Cortex. Grafana поддерживает несколько источников Prometheus: настройте оба экземпляра и переключайтесь между ними.

Для Kubernetes-кластеров рекомендую статью Пошаговая настройка мониторинга и алертинга в Kubernetes с Prometheus, Grafana и Alertmanager. Там разобран высокодоступный вариант развёртывания через Helm.

Типичные ошибки при внедрении проактивного мониторинга и как их избежать

Первая ошибка - слишком много алертов. Когда каждое незначительное отклонение генерирует уведомление, команда перестаёт на них реагировать. Наступает алерт-усталость: критический алерт теряется среди десятков предупреждений. Решение: начинайте с 5–7 алертов на самые критичные сервисы. Добавляйте новые правила только после того, как текущие работают стабильно и не дают ложных срабатываний.

Вторая ошибка - неправильные пороги. Слишком жёсткие пороги дают ложные срабатывания при каждой сетевой флуктуации. Слишком мягкие - пропускают реальные инциденты. Решение: соберите метрики за 2–3 недели в обычном режиме, вычислите базовые значения и установите пороги с запасом 20–30%.

Третья ошибка - отсутствие документации. Конфигурации Prometheus, Blackbox Exporter и Alertmanager со временем усложняются. Без документации новый инженер потратит часы на разбор, а при аварии время критично. Решение: храните конфигурации в Git, описывайте назначение каждого алерта в комментариях, ведите краткий runbook по типовым инцидентам.

Четвёртая ошибка - игнорирование метрик самого мониторинга. Prometheus, Grafana и Alertmanager тоже потребляют ресурсы и могут деградировать. Настройте мониторинг мониторинга: отслеживайте prometheus_tsdb_blocks_loaded, prometheus_engine_query_duration_seconds, использование памяти контейнеров. Импортированный дашборд 3662 покрывает эти метрики.

Заключение: следующие шаги по улучшению мониторинга

Вы развернули стек Prometheus, Grafana, Blackbox Exporter и Alertmanager. Настроили синтетические проверки HTTP, ICMP и TCP. Определили ключевые метрики: up, probe_duration_seconds, probe_http_status_code. Создали правила алертов с порогами и маршрутизацию уведомлений в Slack и email. Построили дашборды для визуализации состояния сервисов.

Следующие шаги для развития системы. Добавьте node_exporter для сбора метрик CPU, памяти и дисков с серверов - это дополнит внешние проверки Blackbox Exporter внутренними данными. Внедрите postgres_exporter и redis_exporter для мониторинга баз данных. Определите SLO и SLI для критичных сервисов и настройте алерты на основе error budget. Для оценки эффективности инфраструктуры после запуска поможет статья Как оценить эффективность инфраструктуры и кода после запуска проекта.

Примените эти настройки на практике. Начните с трёх критичных сервисов, соберите метрики за неделю, уточните пороги. Затем расширяйте покрытие. Проактивный мониторинг окупается первым же предотвращённым инцидентом.

Поделиться:
Сохранить гайд? В закладки браузера