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)

Признак создания объекта VMAlertmanager
Образ config-reloader, отслеживающий изменения конфигурации
Образ 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)

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

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

Поля объекта `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 поднялся и принимает конфигурацию:

Убедитесь, что поды Alertmanager запущены в namespace monitoring:
```
kubectl get pods -n monitoring
```
Проверьте, что создан объект VMAlertmanager:
```
kubectl get vmalertmanager -n monitoring
```
Проверьте, что конфигурация принята (для способа с VMAlertmanagerConfig):
```
kubectl get vmalertmanagerconfig -n monitoring
```
Посмотрите логи Alertmanager на предмет ошибок конфигурации:
```
kubectl logs -n monitoring -l app.kubernetes.io/name=alertmanager --tail=100
```
Откройте веб-интерфейс 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` и адрес записи метрик