Мониторинг и алертинг распределенных систем: практическое руководство по Prometheus и Grafana для контроля SLA

Чтобы контролировать SLA распределенных систем, нужен комплексный мониторинг, который отслеживает не только доступность сервисов, но и предвестники проблем. Эта инструкция показывает, как настроить такой мониторинг с помощью Prometheus и Grafana в 2026 году. Вы получите готовые конфигурации для сбора метрик health checks, состояния circuit breakers и статистики ошибок, примеры правил алертинга и шаблоны дашбордов, которые можно скопировать и применить в своей среде за несколько часов.

Система, построенная по этому руководству, переводит мониторинг из реактивного режима в проактивный. Вместо того чтобы реагировать на уже случившийся сбой, вы будете получать алерты о рисках его возникновения, например, при открытии circuit breaker или росте ошибок выше 2%. Это позволяет устранять проблемы до того, как они повлияют на пользователей, что напрямую повышает стабильность сервисов и соблюдение SLA.

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

Эффективный мониторинг для контроля SLA строится на четырех типах метрик: health checks, состояние circuit breakers, статистика ошибок и расчет доступности. Эти данные собирают с каждого микросервиса через экспортеры или инструментацию кода, передают в Prometheus, где на их основе вычисляют алерты в Alertmanager, а затем визуализируют в Grafana. Такой подход дает полную картину состояния системы в реальном времени.

От реактивного к проактивному мониторингу: почему health checks и circuit breakers - это основа

Простого мониторинга статуса «жив/мертв» (up/down) недостаточно для соблюдения SLA. Падение health check - это уже инцидент, который нарушает доступность. Открытие circuit breaker - это сигнал о том, что сервис испытывает проблемы с зависимостями или нагрузкой и вскоре может полностью отказать. Можно провести аналогию с автомобилем: health check - это чек-энджин, который загорается при поломке, а circuit breaker - лампочка давления масла, которая предупреждает о потенциальной проблеме до катастрофы. Мониторинг этих показателей позволяет действовать на опережение.

Ключевые метрики для расчета SLA: от сырых данных до бизнес-показателей

SLA (Service Level Agreement) для технических специалистов - это измеримый показатель доступности. Его стандартная формула: (общее время - время недоступности) / общее время * 100%. В метриках Prometheus это выражается через запросы к данным о запросах и ошибках. Например, чтобы рассчитать текущую частоту ошибок HTTP 5xx для сервиса «my-service» за последние 5 минут, используют выражение:sum(rate(http_requests_total{status=~"5..", job="my-service"}[5m])) / sum(rate(http_requests_total{job="my-service"}[5m])). Для полного контроля SLA нужны счетчики (counters) для ошибок, гистограммы (histograms) для задержек (latency) и датчики (gauges) для состояния health checks и circuit breakers.

Инструментация приложения: как экспортировать метрики в Prometheus

Первый шаг - заставить приложение отдавать метрики. Для этого используют готовые экспортеры и клиентские библиотеки, которые встраивают в код.

Готовые экспортеры и библиотеки: быстрый старт

Для быстрого получения базовых метрик инфраструктуры установите Node Exporter для мониторинга сервера (CPU, память, диск) и Blackbox Exporter для проверки доступности эндпоинтов (health checks) извне. Для приложений на Spring Boot активируйте эндпоинт /actuator/prometheus, добавив зависимость spring-boot-starter-actuator и micrometer-registry-prometheus в pom.xml. Для приложения на Go добавьте простую кастомную метрику с помощью библиотеки prometheus/client_golang:

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    httpRequestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests.",
        },
        []string{"method", "status", "handler"},
    )
)

func init() {
    prometheus.MustRegister(httpRequestsTotal)
}

// В обработчике запроса
httpRequestsTotal.WithLabelValues(r.Method, "200", r.URL.Path).Inc()

Избегайте типичных ошибок: используйте осмысленные названия метрик в нижнем регистре с подчеркиваниями и согласованные label для группировки.

Сбор метрик состояния Circuit Breaker и Health Checks

Для мониторинга состояния Circuit Breaker в Java-приложении с Resilience4j настройте экспорт метрик в Prometheus. Добавьте в application.yml:

management:
  endpoints:
    web:
      exposure:
        include: health, prometheus, metrics
  metrics:
    export:
      prometheus:
        enabled: true
resilience4j:
  circuitbreaker:
    instances:
      backendService:
        register-health-indicator: true
        sliding-window-size: 10

Prometheus будет собирать метрики вида resilience4j_circuitbreaker_state{name="backendService",state="OPEN"} со значениями 0 или 1 для каждого состояния (CLOSED, OPEN, HALF_OPEN). Для health checks в Kubernetes настройте readiness и liveness пробы, а их статус можно проверять через Blackbox Exporter, нацеленный на эндпоинт /health, или экспортировать как кастомный gauge из самого приложения.

Настройка Prometheus: сбор, хранение и правила алертинга

После инструментации приложений настройте Prometheus для сбора метрик и Alertmanager для отправки уведомлений.

Конфигурация `prometheus.yml` для распределенной среды

Используйте этот каркас конфигурационного файла для продакшен-среды с автоматическим обнаружением сервисов в Kubernetes и статическими таргетами для экспортеров. Задайте интервалы сбора и оценки правил.

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

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

scrape_configs:
  - job_name: 'kubernetes-services'
    kubernetes_sd_configs:
      - role: endpoints
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']
    metrics_path: /metrics

  - job_name: 'blackbox-exporter-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - 'http://my-service:8080/health'
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Правильное именование job и использование label (например, instance, job) критически важно для фильтрации метрик в алертах и дашбордах.

Пишем эффективные правила алертов: примеры для health checks, circuit breakers и ошибок

Создайте файл alerting_rules.yml с правилами, которые срабатывают на ключевые события. Каждое правило содержит выражение (expr), длительность (for), чтобы избежать ложных срабатываний, и аннотации с описанием.

groups:
  - name: sla_alerts
    rules:
      # Алерт на падение health check
      - alert: ServiceHealthCheckFailed
        expr: up{job="blackbox-exporter-http"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Сервис {{ $labels.instance }} недоступен"
          description: "Health check для {{ $labels.instance }} не отвечает более 1 минуты."

      # Алерт на открытие circuit breaker
      - alert: CircuitBreakerTripped
        expr: resilience4j_circuitbreaker_state{state="OPEN"} == 1
        for: 30s
        labels:
          severity: warning
        annotations:
          summary: "Circuit Breaker {{ $labels.name }} открыт"
          description: "Circuit Breaker для сервиса {{ $labels.name }} открыт более 30 секунд. Возможна деградация функциональности."

      # Алерт на рост ошибок 5xx выше 2%
      - alert: ErrorRateSpike
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.02
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Высокий уровень ошибок в сервисе {{ $labels.job }}"
          description: "Доля ошибок 5xx превысила 2% за последние 5 минут. Текущее значение: {{ $value }}."

Порог в 2% и длительность в 5 минут - это примерные значения, которые нужно адаптировать под конкретные SLA ваших сервисов.

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

Чтобы управлять потоком уведомлений и отправлять их в нужные каналы, настройте alertmanager.yml. Конфигурация группирует алерты, задает задержку перед отправкой и определяет правила подавления.

global:
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alerts@yourcompany.com'
  smtp_auth_username: 'your-email@gmail.com'
  smtp_auth_password: 'your-password'

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'slack-devops'

receivers:
  - name: 'slack-devops'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/TOKEN'
        channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}\n{{ end }}'

  - name: 'email-admin'
    email_configs:
      - to: 'admin@yourcompany.com'

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Правило inhibit_rules в примере подавляет warning-алерты для того же сервиса и типа события, если уже сработал critical-алерт, что снижает информационный шум. Для отправки в Telegram используйте соответствующий webhook в блоке receivers.

Создание дашбордов в Grafana для контроля SLA и состояния системы

Дашборды в Grafana превращают сырые метрики из Prometheus в наглядную информацию для принятия решений.

Запросы PromQL для ключевых виджетов: SLA, ошибки, latency

Основу дашборда составляют правильно составленные запросы PromQL. Для панели типа «Stat», отображающей доступность сервиса «api» за последние 30 дней, используйте запрос:sum(rate(http_requests_total{status!~"5..", job="api"}[30d])) / sum(rate(http_requests_total{job="api"}[30d])) * 100. Для мониторинга текущей частоты ошибок на графике подойдет: rate(http_requests_total{status=~"5..", job="api"}[5m]). А для отображения 95-го перцентиля задержки ответа используйте функцию гистограммы: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, job)). Эти формулы можно скопировать прямо в редактор запросов Grafana.

Визуализация состояния Circuit Breakers и Health Checks

Для отображения нечисловых состояний, таких как OPEN/CLOSED или Healthy/Unhealthy, используйте панель «State Timeline». Она показывает временные интервалы, в течение которых метрика имела определенное значение. Запрос может выглядеть так: resilience4j_circuitbreaker_state. Grafana автоматически раскрасит отрезки времени в зависимости от значения метрики (например, красный для OPEN, зеленый для CLOSED). Альтернативно, для сводного статуса всех health checks создайте панель «Stat», выберите режим отображения «Background» и используйте запрос, который возвращает 0, если все проверки успешны, и 1, если хотя бы одна упала. Это даст мгновенное визуальное представление о здоровье системы.

Структура дашборда «SLA и Health Overview» может быть такой:

Верхний ряд: синтетические индикаторы (SLA за сегодня/неделю/месяц, сводный статус health checks).
Средний ряд: графики скорости ошибок (rate 5xx) и времени ответа (latency percentiles) по ключевым сервисам.
Нижний ряд: визуализация состояния circuit breakers (State Timeline) и таблица с текущими активными алертами из Alertmanager.

Готовый JSON такого дашборда можно экспортировать из Grafana и импортировать в свою установку. Подробнее о создании информативных дашбордов для SRE читайте в нашем практическом руководстве по наблюдаемости для высоконагруженных систем.

Практическое внедрение: оценка времени, ресурсов и проверка работоспособности

Внедрение описанного стека мониторинга разбивается на четкие этапы с оценкой времени.

Чек-лист запуска и проверки конфигурации

После настройки каждого компонента выполните проверки из этого чек-листа, чтобы убедиться в работоспособности системы:

Инструментация приложения: Выполните запрос к эндпоинту метрик: curl http://your-service:8080/actuator/prometheus (для Spring Boot). Убедитесь, что в ответе есть ожидаемые метрики, например, http_requests_total.
Prometheus сбор: Откройте веб-интерфейс Prometheus (http://prometheus:9090/targets). Убедитесь, что статус всех ваших таргетов (jobs) - «UP».
Правила алертинга: Перейдите на страницу http://prometheus:9090/rules. Убедитесь, что ваши правила из файла alerting_rules.yml загружены и отображаются.
Тестовый алерт: Для проверки Alertmanager отправьте тестовый алерт через его API: curl -H "Content-Type: application/json" -d '[{"labels":{"alertname":"TestAlert"}}]' http://alertmanager:9093/api/v1/alerts. Уведомление должно прийти в настроенный канал (Slack, Telegram, Email).
Дашборд Grafana: В Grafana создайте новую панель, вставьте один из PromQL-запросов из статьи (например, для расчета ошибок). Убедитесь, что график строится и данные актуальны.

Поэтапный план внедрения для небольшого кластера из 3-5 сервисов:

Развертывание инфраструктуры (15-30 минут): Установите Prometheus, Grafana и Alertmanager через Docker или Helm-чарты. Для быстрого старта можно использовать нашу полную инструкцию по развертыванию стека мониторинга с нуля.
Инструментация пилотного сервиса (30-60 минут): Добавьте экспорт метрик в один ключевой микросервис, как описано в разделе про инструментацию.
Настройка алертов и дашборда (60 минут): Настройте базовые правила алертинга для этого сервиса и создайте первый дашборд в Grafana.

Ориентировочные требования к ресурсам для стека, мониторящего 10-15 сервисов: Prometheus - 2-4 ГБ RAM, 50 ГБ диска для хранения временных рядов; Grafana - 1 ГБ RAM; Alertmanager - 512 МБ RAM. Обязательно тестируйте алерты в контролируемых условиях, например, временно увеличив нагрузку на сервис или сымитировав ошибку через запрос к специальному эндпоинту. После запуска мониторинга важно оценить его влияние на стабильность. Методику такой оценки вы найдете в руководстве по оценке эффективности инфраструктурного проекта.

Для автоматизации и управления конфигурациями мониторинга в сложных распределенных системах рассмотрите возможность использования агрегатора API, такого как AiTunnel. Он предоставляет единый интерфейс для доступа к различным сервисам, что может упростить интеграцию систем алертинга с другими внутренними инструментами.