Настройка оповещений

Установка по умолчанию

При развертывании системы, устанавливается интеграция с alertmanager как средство оповещения по умолчанию. Данный компонент поддерживает много разных типов каналов оповещений, например:

  • email

  • Telegram

  • Discord

  • Jira

  • Mattermost (Slack)

  • MS Teams

  • OpsGenie

  • PagerDuty

  • VictorOps

  • SNS (Amazon AWS)

  • Webex

  • Webhook

Правила оповещений о событиях описаны в конфигурационном файле:

  • ./templates/alertmanager-cm.yaml - в случае установки в кластер Kubernetes

  • ./alertmanager/config/alertmanager.yml - в случае установки в виде Docker Compose

Настройки описываются в формате YAML. Например, для интеграции с Mattermost необходимо подставить <webhookid> и <channel-name> в блок slack_configs группы receivers и т.д. Имя канала оповещений (receiver) задается произвольно. Неиспользуемые каналы можно удалить из конфигурации.

alertmanager.yml
global:
templates:
- '/etc/alertmanager-templates/*.tmpl'
route:
  receiver: alert-null  # канал для отправки всех сообщений по умолчанию.
  # В примере указана пустая заглушка для отправки сообщений только по указанным далее маршрутам.
  # Может быть использован любой другой канал.
  group_by: ['alertname', 'hostname', 'group', 'severity', 'metric']
  group_wait: 3m
  group_interval: 5m
  repeat_interval: 1d
  routes:
  - receiver: alert-mmost
    matchers: # задаем условия для отправки сообщений через этот канал
    - team = ipa_support
  - receiver: alert-telegram1
    matchers:
    - group = infra
  - receiver: send-to-telegram2
    matchers:
    - group = middleware
    - severity =~ "warning|critical"
  - receiver: email-alerts
    matchers:
    - group = middleware
    - severity = critical

receivers:
- name: alert-mmost1
  slack_configs:
  - api_url: https://im.astralinux.ru/hooks/<webhookid>
    channel: '<channel-name>'  # имя канала в mattermost
    send_resolved: true
    title: '{{ template "slack.title" . }}'
    color: '{{ template "slack.color" . }}'
    text: '{{ template "slack.text" . }}'
- name: alert-telegram1
   # Оповещения в первую группу telegram
  telegram_configs:
  - bot_token: '<bot_token>'   # https://core.telegram.org/bots/features#botfather
    api_url: 'https://api.telegram.org'
    # Не забудьте добавить бота в группу, в которую должны приходить сообщения
    chat_id: -1000000000001 # <указать id группы в формате -1234567890, в начале стоит минус
    send_resolved: true
    message: '{{ template "telegram.message" . }}'
- name: send-to-telegram2
  # Оповещения во вторую группу telegram (при необходимости)
  telegram_configs:
  - bot_token: '<bot_token>'
    api_url: 'https://api.telegram.org'
    chat_id: -1000000000002
    send_resolved: true
    message: '{{ template "telegram.message" . }}'
- name: email-alerts
  email_configs:
  - to: email@example-domain.ru
        send_resolved: false
        from: astra-monitoring@example-domain.ru
        smarthost: <smtp-relay-address>:25
        require_tls: false
- name: alert-null   # пустой канал-заглушка

inhibit_rules:
  - source_matchers: [severity="critical"]
    target_matchers: [severity="warning"]
    # Apply inhibition if the alertname is the same.
    # CAUTION:
    #   If all label names listed in `equal` are missing
    #   from both the source and target alerts,
    #   the inhibition rule will apply!
    equal: [alertname, hostname, instance, group]

Webhook-интеграции

Система поддерживает интеграцию с внешними сервисами через Webhook, что позволяет подключить каналы оповещений, не поддерживаемые нативно Alertmanager. Среди совместимых сервисов:

  • GitLab

  • Ansible Tower

  • IRC-чаты

  • Zoom

  • SMS-шлюзы

  • Другие веб-сервисы

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

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

Каналы оповещений настраиваются в секции receivers. Для каждого канала указываются:

  1. Уникальное имя получателя

  2. Специфичные параметры:

    • Email: адреса получателей

    • Telegram: токен бота и ID чата

    • Webhook: URL эндпоинта

Можно создать несколько получателей одного типа с разными параметрами.

Маршрутизация оповещений

Логика распределения оповещений по каналам задаётся в секции route:

  • default - канал для оповещений без специальных условий

  • matchers - условия маршрутизации на основе лейблов:

    matchers:
  - group = "middleware"
  - severity =~ "warning|critical"

Выбор того или иного канала оповещений зависит от условий, заданных в секции route, включая канал «по умолчанию» (в примере выше это alert-null), куда будут отправляться все оповещения. Для остальных маршрутов условия задаются в блоке matchers маршрута. Например, это может быть проверка на значение каких-либо лейблов - severity, group и т.д. Оповещение может быть отправлено в несколько разных каналов. Так, в примере выше описана отправка в telegram2 алертов, у которых лейбл group = «middleware», а severity = «warning» или «critical». При этом, алерты с лейблами group = «middleware» и severity = «critical» будут также дублироваться на электронную почту из канала email-alerts.

Группировка оповещений

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

  1. group_by
    Определяет метки для объединения связанных оповещений в группы.
    Пример: group_by: ['host', 'service'] объединит все алерты от одного хоста и сервиса.

  2. group_wait (по умолчанию: 30 секунд)
    Время ожидания перед отправкой первой группы оповещений.
    Позволяет собрать связанные события в одно уведомление.

  3. group_interval (по умолчанию: 5 минут)
    Интервал между отправками обновлений для существующей группы.

  4. repeat_interval (по умолчанию: 4 часа)
    Периодичность повторных уведомлений о нерешенных проблемах.

Пример конфигурации:

route:
  group_by: ['host']
  group_wait: 1m
  group_interval: 10m
  repeat_interval: 6h

Подавление избыточных оповещений

В секции inhibit_rules можно настроить правила для:

  • Автоматического подавления менее важных оповещений

  • Уменьшения информационного шума при критических событиях

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

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

Это правило отключает warning-оповещения при наличии критических событий с теми же метками.

Активные настройки Alertmanager, его состояние и список активных алертов можно проверить в web-интерфейсе по доменному имени, заданному при развертывании в среде Kubernetes (например, вида https://alertmanager.am.domain.local/) или по порту 9093 при развертывании в среде Docker Compose (вида http(s)://astra-monitoring.server:9093/). Также, используя API Alertmanager, возможно проверять его состояние GET-запросами по пути /-/healthy, /-/ready или инициировать перезагрузку конфигурации POST-запросом по пути /-/reload.

Более подробно о возможностях настройки подсистемы оповещения можно найти в официальной документации.

После внесения изменений, необходимо обновить компоненты Платформы с помощью инструментов docker-compose / helm-chart.