Настройка алертинга в Prometheus и Alertmanager 2026: практическое руководство с готовыми конфигами | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Настройка алертинга в Prometheus и Alertmanager 2026: практическое руководство с готовыми конфигами

20 апреля 2026 7 мин. чтения
Содержание статьи

Настроить эффективную систему алертинга - это не просто подключить Prometheus к Alertmanager. Это выстроить логику, при которой каждый алерт сигнализирует о реальной проблеме, а не создает информационный шум. Это практическое руководство проведет вас от создания базовых правил в alert.rules.yml до тонкой настройки группировки, подавления и маршрутизации в Alertmanager. Вы получите готовые, проверенные на практике конфигурации для мониторинга сервисов, ресурсов и сети, которые можно адаптировать под вашу инфраструктуру и запустить уже сегодня.

От метрик к действию: философия и базовая настройка алертинга

Сбор метрик - это наблюдение. Алертинг - это действие. Цель - не просто зафиксировать аномалию, а инициировать осмысленную реакцию. Настройка начинается с двух обязательных шагов: указания Prometheus на адрес Alertmanager в файле prometheus.yml и создания файла правил.

В prometheus.yml добавьте секцию:

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - 'alertmanager:9093' # Ваш адрес Alertmanager

Затем создайте файл /etc/prometheus/alert.rules.yml и подключите его в том же prometheus.yml:

rule_files:
  - "alert.rules.yml"

Базовое правило алертинга состоит из пяти ключевых частей: имя (alert), условие (expr), длительность (for), метки (labels) и аннотации (annotations). Аннотации - это информация для человека, которая попадет в уведомление.

Структура файла alert.rules.yml: разбираем каждую директиву

Разберем структуру на примере правила для обнаружения недоступной ноды.

groups:
  - name: node_alerts
    rules:
      - alert: InstanceDown
        # Выражение на PromQL: метрика `up` равна 0 более 1 минуты.
        expr: up == 0
        # Длительность: алерт сработает, если условие истинно 1 минуту.
        # Это фильтр кратковременных «дребезгов» (flapping).
        for: 1m
        # Метки: классифицируют алерт для маршрутизации в Alertmanager.
        labels:
          severity: critical
          team: infra
        # Аннотации: пояснительный текст для уведомления.
        annotations:
          summary: "{{ $labels.instance }} недоступен"
          description: "Экспортер Prometheus на {{ $labels.instance }} не отдает метрики более 1 минуты."
          runbook_url: "https://wiki.internal/runbooks/instance-down"
  • expr: Это ядро правила. Используйте PromQL для описания аномального состояния. Всегда проверяйте выражение в разделе Graph веб-интерфейса Prometheus перед добавлением в конфигурацию.
  • for: Критически важный параметр для борьбы с ложными срабатываниями. Он задает период, в течение которого условие должно быть истинным, прежде чем алерт перейдет в состояние firing. Для ресурсных алертов (CPU, память) используйте for: 5m или больше, чтобы отсечь кратковременные пики.
  • labels: Ключевые метки - severity (critical, warning, info) и team (infra, app, db). Они используются Alertmanager для группировки и маршрутизации.
  • annotations: Поля summary (кратко) и description (подробно) обязательны. runbook_url - лучшая практика, дающая инженеру немедленное руководство к действию.

Пишем эффективные правила: от абстракции к конкретным примерам

Теория без практики бесполезна. Следующие правила проверены в production-средах и покрывают основные сценарии мониторинга. Каждое правило содержит пояснение логики и выбранных порогов.

Мониторинг состояния сервисов и доступности

Эти правила отслеживают базовую работоспособность инфраструктуры.

  - alert: ServiceDown
    expr: up{job="node-exporter"} == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Нода {{ $labels.instance }} недоступна"

  - alert: HTTPProbeFailed
    # Используется blackbox_exporter
    expr: probe_success{job="blackbox-http"} == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Эндпоинт {{ $labels.instance }} не отвечает"

  - alert: HighServiceLatency
    # 95-й перцентиль времени ответа больше 500мс
    expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 0.5
    for: 3m
    labels:
      severity: warning
    annotations:
      summary: "Высокая задержка сервиса {{ $labels.service }}"

Контроль потребления ресурсов: память, CPU, диск

Ресурсные алерты требуют осмысленных порогов и обязательного использования for.

  - alert: DiskWillFillIn24Hours
    # Прогноз заполнения диска на основе скорости роста за последний час.
    expr: predict_linear(node_filesystem_free_bytes{job="node"}[1h], 3600*24) < 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "На {{ $labels.instance }} диск {{ $labels.mountpoint }} заполнится в течение 24 часов"

  - alert: HighMemoryUsage
    # Использование памяти (без учета кэша) больше 85%
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
    for: 10m
    labels:
      severity: warning

  - alert: HighCpuLoad
    # Средняя загрузка CPU за 5 минут больше 80%
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: warning

Для комплексного понимания основ мониторинга, включая сбор этих метрик, обратитесь к нашему практическому руководству по администрированию Linux.

Мониторинг сетевой связности и бизнес-логики

Переход от системных метрик к метрикам приложения.

  - alert: HighErrorRate
    # Более 5% HTTP-запросов возвращают ошибку 5xx
    expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) / rate(nginx_http_requests_total[5m]) * 100 > 5
    for: 2m
    labels:
      severity: critical

  - alert: BusinessTransactionsDown
    expr: rate(application_transactions_success_total[10m]) < 10
    for: 5m
    labels:
      severity: critical
      team: app

Alertmanager: борьба со спамом и умная маршрутизация

Alertmanager превращает поток сырых алертов из Prometheus в управляемые уведомления. Его конфигурация, alertmanager.yml, строится вокруг трех ключевых концепций: группировки (group_by), подавления (inhibit_rules) и маршрутизации (routes).

Группировка (grouping): объединяем похожие инциденты

При падении целого кластера нет смысла получать десятки отдельных писем. Группировка объединяет алерты по заданным меткам.

route:
  # Группировать алерты по имени алерта и кластеру.
  group_by: ['alertname', 'cluster']
  # Ждать 30 секунд, чтобы собрать все алерты одной группы перед первым уведомлением.
  group_wait: 30s
  # Интервал отправки повторных уведомлений для группы, если проблема не решена.
  group_interval: 5m
  # Интервал повторной отправки одного и того же алерта.
  repeat_interval: 4h
  receiver: 'slack-default'

Настройка group_by: ['alertname', 'cluster'] означает, что все алерты InstanceDown в кластере prod-eu придут одним сообщением.

Подавление (inhibition): отключаем шум зависимых алертов

Подавление отключает одни алерты при срабатывании других, более критичных. Классический пример: если нода упала, не нужно слать алерты о высокой загрузке CPU на этой ноде.

inhibit_rules:
  - source_match:
      severity: 'critical'
      alertname: 'NodeDown'
    target_match:
      severity: 'warning'
    # Подавить целевые алерты, если метка `instance` совпадает.
    equal: ['instance', 'cluster']

Это правило гласит: если сработал критический алерт с именем NodeDown, то подавить все варнинги с такими же значениями меток instance и cluster.

Роутинг (routing) и получатели: правим оповещения нужным людям

Дерево маршрутов направляет алерты разной критичности в разные каналы.

route:
  group_by: ['alertname', 'cluster']
  receiver: 'slack-all'
  routes:
    # Критические алерты идут в PagerDuty и отдельный Slack-канал.
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      continue: true # Продолжить обработку по дереву.
    - match:
        severity: critical
      receiver: 'slack-critical'
    # Ворнинги только в Slack.
    - match:
        severity: warning
      receiver: 'slack-warning'
    # Аллерты для команды БД - в их Slack-канал.
    - match:
        team: db
      receiver: 'slack-db-team'

receivers:
  - name: 'slack-critical'
    slack_configs:
      - channel: '#alerts-critical'
        send_resolved: true
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: ''
  - name: 'slack-warning'
    slack_configs:
      - channel: '#alerts-warning'
        send_resolved: true

Настройка continue: true позволяет критическому алерту пройти по нескольким маршрутам, например, попасть и в PagerDuty, и в Slack.

Сборка production-конфигурации: итоговые файлы и best practices

Объединим все компоненты в готовые для использования конфигурационные файлы.

Готовые конфигурации для копирования

Файл alert.rules.yml (сокращенный пример):

groups:
  - name: infrastructure
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} недоступен"

      - alert: DiskWillFillIn24Hours
        expr: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[1h], 3600*24) < 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Диск на {{ $labels.instance }} заполнится в течение 24 часов"

  - name: application
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 2m
        labels:
          severity: critical
          team: app

Файл alertmanager.yml (базовый production-вариант):

global:
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alerts@yourcompany.com'
  smtp_auth_username: 'alerts@yourcompany.com'
  smtp_auth_password: 'your_password'

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'email-default'

  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      continue: true
    - match:
        severity: critical
      receiver: 'slack-critical'
    - match:
        severity: warning
      receiver: 'slack-warnings'

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

receivers:
  - name: 'email-default'
    email_configs:
      - to: 'infra-team@yourcompany.com'
  - name: 'slack-critical'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#alerts-critical'
  - name: 'slack-warnings'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#alerts-warnings'
  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: 'your_pagerduty_integration_key'

Что нужно заменить под свою инфраструктуру:

  • В alert.rules.yml: имена меток (instance, mountpoint), пороги загрузки CPU/памяти, названия jobs.
  • В alertmanager.yml: SMTP-сервер и учетные данные, Slack Webhook URLs, PagerDuty routing key, email-адреса получателей.

Как тестировать и поддерживать ваши алерты

Запуск непроверенных алертов в production - прямой путь к alert fatigue (усталости от оповещений). Используйте официальные инструменты валидации.

  • Prometheus Rule Tester: Утилита promtool проверяет синтаксис файлов правил.
    promtool check rules alert.rules.yml
  • Alertmanager CLI: Утилита amtool позволяет проверять конфигурацию маршрутов.
    amtool check-config alertmanager.yml
  • Регулярный ревью: Раз в квартал анализируйте сработавшие алерты. Отключайте те, что никогда не срабатывают или всегда срабатывают ложноположительно. Каждый алерт должен иметь владельца (team label) и runbook.
  • Мониторинг алертинга: Создайте правило, которое следит за самим алертингом.
      - alert: PrometheusAlertmanagerNotificationFailed
    expr: rate(alertmanager_notifications_failed_total[5m]) > 0
    for: 5m
    labels:
      severity: critical

Следование этим принципам - осмысленные пороги, обязательное использование for, информативные аннотации с runbook и регулярное тестирование - превратит вашу систему алертинга из источника шума в надежный механизм раннего оповещения. Для автоматизации подобных инфраструктурных задач рекомендуем ознакомиться с нашим практическим гайдом по автоматизации инфраструктуры.

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