Alertmanager

Описание

Alertmanager — компонент стека мониторинга, который принимает алерты от vmalert, группирует их, подавляет дубли и маршрутизирует настроенным получателям (электронная почта, webhook и другие).
В платформе Боцман Alertmanager входит в состав аддона victoria-metrics и запускается автоматически при запуске victoria-metrics.

Поток событий мониторинга выглядит так:

метрики → vmagent → vmsingle (хранилище) → vmalert (правила алертинга) → alertmanager → получатель (e-mail, webhook, ...)

Назначение звеньев цепочки:

• vmagent — собирает метрики с узлов и приложений;
• vmsingle — хранит метрики и отдаёт их по Prometheus-совместимому API;
• vmalert — вычисляет правила алертинга и порождает алерты;
• alertmanager — группирует алерты и рассылает их по настроенным получателям.

Правилами по умолчанию (defaultRules) уже заведены проверки для etcd, kube-apiserver, kubelet, узлов и приложений Kubernetes.

Заметка

По умолчанию Alertmanager настроен на получатель-заглушку blackhole: алерты формируются, но никуда не отправляются. Пока не задан рабочий получатель, оповещения уходить не будут.

Пререквизиты

Перед активацией убедитесь, что выполнены условия:

• Модуль хранения данных (Longhorn, Ceph CSI и т. п.) установлен и назначен классом по умолчанию (default StorageClass). Без него vmsingle не запустится, PVC останется в состоянии Pending, и мониторинг в целом не заработает.

Активация

1. Через веб-интерфейс

В разделе Управление кластером → Аддоны найдите аддон victoria-metrics,включите его и примените конфигурацию.

В блоке конфигурации Alertmanager уже активен (alertmanager.enabled: true).

2. Командой

Выполните включение аддона victoria-metrics в нужном кластере:

kubectl patch Config.addon.bootsman.tech {++CLUSTER_NAME++}-victoria-metrics \
  --type=merge --patch="{\"spec\": {\"enabled\": true}}"

Дополнительная настройка не требуется: Alertmanager включается в составе модуля.

Блок Alertmanager в значениях values аддона выглядит так:

alertmanager:
  enabled: true (1)
  spec:
    configReloaderImageTag: harbor.bootsman.host/bootsman-nimbus/common-artifacts/victoriametrics-configmap-reload:v0.8.0 (2)
    image:
      repository: harbor.bootsman.host/bootsman-nimbus/common-artifacts/victoriametrics-alertmanager
      tag: v0.28.1 (3)

1. Признак создания объекта VMAlertmanager
2. Образ config-reloader, отслеживающий изменения конфигурации
3. Образ Alertmanager

Сценарии работы: кластерный и централизованный мониторинг

Alertmanager работает в одном из двух сценариев работы мониторинга:

• Кластерный мониторинг
• Централизованный мониторинг

Настройка оповещений на электронную почту

Через VMAlertmanagerConfig

При этом способе конфигурация хранится как отдельный объект VMAlertmanagerConfig, а Alertmanager подхватывает её автоматически (selectAllByDefault: true). Маршруты и получатели описываются декларативно и не смешиваются с секретами.

Сначала создайте Secret с паролем от почтового ящика:

apiVersion: v1
kind: Secret
metadata:
  name: smtp-credentials
  namespace: monitoring
type: Opaque
stringData:
  password: {++SMTP_PASSWORD++}

Затем создайте конфигурацию Alertmanager с получателем, отправителем и SMTP-сервером:

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlertmanagerConfig
metadata:
  name: email
  namespace: monitoring
spec:
  route:
    receiver: email (1)
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 4h
  receivers:
    - name: email
      email_configs:
        - to: {++RECIPIENT_EMAIL++} (2)
          from: {++SENDER_EMAIL++} (3)
          smarthost: {++SMTP_HOST:PORT++} (4)
          auth_username: {++SMTP_USERNAME++}
          auth_password:
            name: smtp-credentials
            key: password
          require_tls: false (5)
          send_resolved: true (6)
          tls_config:
            insecure_skip_verify: true (7)

1. Имя получателя, которому маршрутизируются алерты
2. Адрес получателя оповещений
3. Адрес отправителя, от имени которого уходят письма
4. Адрес SMTP-сервера с портом
5. Отключение обязательного TLS-соединения (при необходимости)
6. Уведомлять также о том, что алерт перестал срабатывать
7. Пропуск проверки сертификата (для самоподписанных сертификатов)

Через несколько минут конфигурация применится автоматически, и оповещения начнут отправляться на указанный адрес.

Поля объекта VMAlertmanager

Поля задаются внутри блока alertmanager значения values аддона:

Поле	Значение по умолчанию	Назначение
alertmanager.enabled	true	Создавать объект VMAlertmanager
spec.replicaCount	1	Число реплик Alertmanager
spec.port	"9093"	Порт веб-интерфейса и API
spec.selectAllByDefault	true	Подхватывать все VMAlertmanagerConfig
spec.configSecret	""	Имя Secret с конфигом (если задан — config игнорируется)
spec.externalURL	""	Внешний URL для ссылок в уведомлениях
useManagedConfig	false	false — конфиг в Secret; true — в VMAlertmanagerConfig

Проверка

После включения проверьте, что Alertmanager поднялся и принимает конфигурацию:

1. Убедитесь, что поды Alertmanager запущены в namespace monitoring:

   kubectl get pods -n monitoring

2. Проверьте, что создан объект VMAlertmanager:

   kubectl get vmalertmanager -n monitoring

3. Проверьте, что конфигурация принята (для способа с VMAlertmanagerConfig):

   kubectl get vmalertmanagerconfig -n monitoring

4. Посмотрите логи Alertmanager на предмет ошибок конфигурации:

   kubectl logs -n monitoring -l app.kubernetes.io/name=alertmanager --tail=100

5. Откройте веб-интерфейс Alertmanager (порт 9093) и убедитесь, что алерты видны в разделе Alerts. В интерфейсе также можно временно заглушить алерты (Silences).

При кластерном сценарии ссылки на компоненты мониторинга появляются в разделе Мониторинг интерфейса кластера:

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

Симптом	Причина	Решение
Поды Alertmanager не запускаются, PVC в статусе Pending	Нет StorageClass по умолчанию	Назначьте класс хранения по умолчанию (Longhorn, Ceph CSI)
Алерты формируются, но никуда не уходят	Получатель не настроен, активен blackhole	Настройте VMAlertmanagerConfig или Secret с конфигом
Оповещения не приходят на почту	Не создан Secret с паролем или неверный smarthost	Проверьте VMAlertmanagerConfig, Secret smtp-credentials и SMTP-параметры
Письма не уходят, в логах ошибки TLS	Почтовый сервер использует самоподписанный сертификат	Установите require_tls: false и tls_config.insecure_skip_verify: true (или добавьте CA)
VMAlertmanagerConfig создан, но не применяется	Разные форматы конфигурации у двух способов	Сверьте структуру с выбранным способом (useManagedConfig)
В централизованном сценарии алертов из подчинённых кластеров нет	В подчинённом кластере не отключены лишние компоненты или не задан additionalRemoteWrites	Проверьте значения alertmanager.enabled, vmalert.enabled и адрес записи метрик

Связанные статьи

• Изменение срока хранения метрик в Victoria Metrics
• Мониторинг срока действия сертификатов, выпущенных средствами cert-manager
• Кластерный мониторинг
• Централизованный мониторинг
• Longhorn