Подробный гайд по настройке Alertmanager и интеграции с основными каналами

Гайд по настройке Alertmanager: конфигурация, маршрутизация, интеграция с Email, Slack, Webhook, PagerDuty. Тестирование, безопасность и лучшие практики DevOps.

Подробный гайд по настройке Alertmanager и интеграции с основными каналами Ниже представлен подробный гайд по настройке Alertmanager и интеграции с основными каналами уведомлений без использования иконок. Гайд охватывает базовую архитектуру, синтаксис конфигурации, пошаговую настройку популярных интеграций, маршрутизацию, тестирование и лучшие практики безопасности.

1. Роль Alertmanager в стеке мониторинга

Alertmanager не генерирует алерты.

Он получает их от Prometheus (или других источников через webhook), выполняет:

Дедупликацию (игнорирует идентичные алерты от разных инстансов)
Группировку (объединяет алерты по лейблам)
Маршрутизацию (отправляет в нужный канал по правилам match/match_re)
Уведомления (решение проблем, повторные уведомления, отправка resolved)

2. Базовая структура alertmanager.yml

global:
  resolve_timeout: 5m          # Время ожидания подтверждения resolution
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'user'
  smtp_auth_password_file: '/etc/alertmanager/smtp_pass' # Безопаснее, чем plain text

route:
  receiver: 'default'          # Приёмник по умолчанию
  group_by: ['alertname', 'job', 'namespace']
  group_wait: 30s              # Ожидание перед отправкой первой группы
  group_interval: 5m           # Интервал между отправками обновлений группы
  repeat_interval: 4h          # Как часто повторять алерт, если он не закрыт
  routes:                      # Дерево маршрутов (подробнее в разделе 5)
    - match:
        severity: critical
      receiver: 'pagerduty'
      continue: true           # Позволяет пройти дальше по дереву

receivers:
  - name: 'default'
    # ... каналы уведомлений

templates:                     # Опционально: кастомные Go-шаблоны
  - '/etc/alertmanager/templates/*.tmpl'

Проверка конфига: amtool check-config alertmanager.yml

3. Настройка каналов уведомлений

3.1 Email (SMTP)

Работает с любым SMTP-сервером (Gmail, Yandex, корпоративный Postfix, AWS SES и т.д.).

receivers:
  - name: 'email-team'
    email_configs:
      - to: 'ops-team@company.com, devops@company.com'
        send_resolved: true
        html: |
          <h2>{{ .GroupLabels.alertname }}</h2>
          <p>Status: <b>{{ .Status }}</b></p>
          <table border="1">
            <tr><th>Instance</th><th>Description</th></tr>
            {{ range .Alerts }}
            <tr>
              <td>{{ .Labels.instance }}</td>
              <td>{{ .Annotations.description | default "Нет описания" }}</td>
            </tr>
            {{ end }}
          </table>

Нюансы:

Gmail: используйте App Password, включите 2FA.
Корпоративные SMTP: часто требуют smtp_require_tls: true и сертификаты (smtp_tls_config).
smtp_auth_password_file предпочтительнее plain-text пароля.

3.2 Slack

Требует Incoming Webhook или Slack App с правами chat:write.

receivers:
  - name: 'slack-alerts'
    slack_configs:
      - api_url_file: '/etc/alertmanager/slack_webhook' # Безопасно
        channel: '#monitoring'
        send_resolved: true
        title: '{{ .GroupLabels.alertname }} | {{ .Status | toUpper }}'
        text: >-
          {{ range .Alerts }}
          • *Alert:* {{ .Labels.alertname }}
            *Severity:* {{ .Labels.severity | default "info" }}
            *Summary:* {{ .Annotations.summary }}
            *Instance:* {{ .Labels.instance }}
          {{ end }}
        actions:
          - type: button
            text: 'Open Runbook'
            url: '{{ .CommonAnnotations.runbook_url | default "https://wiki.company.com" }}'

api_url_file читает URL из файла, избегая попадания секретов в лог/репозиторий.
Slack ограничивает ~1 сообщение/сек на канал. При массовых алертах настройте group_wait и group_interval.

3.3 Webhook (универсальный)

Используется для Mattermost, Jira, кастомных API, систем тикетов.

receivers:
  - name: 'custom-webhook'
    webhook_configs:
      - url: 'https://your-endpoint.com/api/alerts'
        send_resolved: true
        http_config:
          bearer_token_file: '/etc/alertmanager/webhook_token'
          tls_config:
            ca_file: '/etc/ssl/certs/ca-bundle.crt'

Формат payload (v2 JSON):

Alertmanager отправляет POST-запрос со структурой:

{
  "status": "firing",
  "alerts": [...],
  "commonLabels": {...},
  "commonAnnotations": {...},
  "externalURL": "http://alertmanager:9093",
  "groupKey": "{}:{alertname=\"HighCPU\"}",
  "truncatedAlerts": 0
}

Для быстрой отладки используйте webhook.site или ngrok.

3.4 PagerDuty / Opsgenie (кратко)

Требуют интеграционные ключи, создаются в веб-интерфейсе сервисов.

receivers:
  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key_file: '/etc/alertmanager/pd_key'
        severity: '{{ .CommonLabels.severity | default "critical" }}'
        description: '{{ .GroupLabels.alertname }}: {{ .CommonAnnotations.summary }}'

  - name: 'opsgenie'
    opsgenie_configs:
      - api_key_file: '/etc/alertmanager/og_key'
        responders:
          - name: 'oncall-team'
            type: team

Оба провайдера автоматически обрабатывают escalation, on-call графики и deduplication.

4. Маршрутизация и группировка

Дерево маршрутов обрабатывается сверху вниз.

Первый совпавший маршрут используется, если `continue: false`.

route:
  receiver: 'default'
  group_by: ['alertname', 'namespace']
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      continue: true               # Пройдёт дальше, чтобы попасть и в Slack

    - match_re:
        service: '^(database|cache)$'
      receiver: 'slack-db-team'
      group_wait: 10s
      repeat_interval: 1h

    - match:
        environment: staging
      receiver: 'email-devs'
      mute_time_intervals: ['night-ops'] # Игнорировать ночью

mute_time_intervals (v0.25+) заменяет старые silences для временных окон.
inhibit_rules позволяют подавлять алерты при наличии более критичных (например, NodeDown подавляет ServiceDown на том же хосте).

5. Тестирование и отладка

Задача	Команда / Способ
Валидация конфига	`amtool check-config alertmanager.yml`
Отправка тестового алерта	`amtool alert add alertname=test_severity=critical`
Проверка маршрута	`amtool config routes test --config.file=alertmanager.yml alertname=HighCPU severity=warning`
Логи отладки	Запуск с `--log.level=debug --log.format=logger:stderr`
Просмотр payload вебхука	`curl -X POST https://webhook.site/your-id -d @- < payload.json`
Проверка SMTP	`telnet smtp.example.com 587` или `openssl s_client -connect smtp:587 -starttls smtp`

Частые ошибки:

failed to resolve template → синтаксис Go-шаблонов нарушен.
connection refused → firewall/прокси блокирует outbound.
rate limit exceeded → слишком частые алерты, увеличьте group_interval.
unauthorized → неверный token/API key или просроченный webhook.

6. Безопасность и лучшие практики

Никогда не храните секреты в alertmanager.yml. Используйте *_file суффиксы и монтируйте через Secrets (K8s, Vault, Ansible).
TLS для всех outbound-соединений: smtp_require_tls: true, http_config.tls_config, Slack уже по умолчанию HTTPS.
Ограничьте доступ к UI: Alertmanager не имеет встроенной авторизации. Используйте reverse (Nginx, Traefik) или Kubernetes Ingress с auth.
Настройте send_resolved: true для всех каналов, иначе команды не узнают о восстановлении.
Версионируйте конфиг: alertmanager.yml → Git → CI/CD → amtool check-config → deploy.
Мониторьте сам Alertmanager: метрики alertmanager_notifications_*, alertmanager_cluster_*, alertmanager_config_last_reload_successful.
Используйте group_by осознанно: слишком узкая группировка → спам, слишком широкая → потеря контекста.