Алертинг

Триггеры

Триггеры (alerting rules) определяют условия создания алертов при отклонении значений метрик от ожидаемых порогов.

Триггеры описываются в группах правил и задаются как элементы массива spec.rules. Если у правила указано поле alert, оно считается триггером и используется для создания алертов.

Виды групп правил с триггерами

Поддерживаются три типа групп правил, в которых могут быть определены триггеры:

Описание типов групп правил:

• Системные группы правил (ClusterObservabilityMetricsRulesGroup) — используются для описания триггеров уровня платформы и компонентов кластера. Создаются и управляются администраторами DKP.

• Проектные группы правил (ObservabilityMetricsRulesGroup) — используются для описания триггеров, относящихся к конкретному проекту (неймспейсу). Пользователи проекта могут создавать и редактировать их в рамках настроенных прав доступа.

• Общедоступные (propagated) группы правил (ClusterObservabilityPropagatedMetricsRulesGroup) — создаются на уровне кластера и автоматически становятся доступны во всех проектах.

Дополнительные лейблы алертов, поставляемых с DKP

Модуль observability позволяет добавлять дополнительные лейблы к триггерам алертов, поставляемых с DKP. Для этого используется ресурс ClusterObservabilityAlertAdditionalLabels.

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

• Добавление лейбла ко всем алертам кластера:

  apiVersion: observability.deckhouse.io/v1alpha1
  kind: ClusterObservabilityAlertAdditionalLabels
  metadata:
    name: all-alerts
  spec:
    alertSelector:
      matchExpressions:
        - key: alertname
          operator: Exists
    additionalLabels:
      example-label-name: example-label-value

• Добавление лейбла severity=Info для алертов с severity_level 7,8,9:

  apiVersion: observability.deckhouse.io/v1alpha1
  kind: ClusterObservabilityAlertAdditionalLabels
  metadata:
    name: severity-info-low-priority
  spec:
    alertSelector:
      matchExpressions:
        - key: severity_level
          operator: In
          values: ["7", "8", "9"]
    additionalLabels:
      severity: Info

• Добавление лейбла team=custom для алертов с указанными именами:

  apiVersion: observability.deckhouse.io/v1alpha1
  kind: ClusterObservabilityAlertAdditionalLabels
  metadata:
    name: deckhouse-team-routing
  spec:
    alertSelector:
      matchExpressions:
        - key: alertname
          operator: In
          values:
            - D8CNIMisconfigured
            - D8DeckhouseIsNotOnReleaseChannel
            - D8DeckhouseIsNotOnReleaseChannel
    additionalLabels:
      team: custom

Группы триггеров

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

Группы удобны для объединения триггеров, относящихся к одному компоненту, сервису или проекту, а также для применения единого интервала вычисления ко всем правилам группы.

Уведомления

Модуль observability предоставляет механизмы настройки доставки уведомлений об алертах и разграничения доступа к каналам уведомлений на уровне кластера и проектов.

Поддерживаются следующие каналы доставки:

• Email;
• Telegram;
• Slack;
• Webhook;
• ExpressMessenger.

Параметры подключения зависят от вида канала и настраиваются через соответствующий Kubernetes-ресурс.

Виды каналов уведомлений

Поддерживаются три типа каналов уведомлений:

Описание видов каналов:

• Системные каналы (ClusterObservabilityNotificationChannel) — используются для доставки уведомлений уровня кластера. Доступны в веб-интерфейсе Deckhouse в разделе «Система» → «Управление системой» → «Мониторинг» → «Настройка уведомлений» → «Каналы уведомлений».

• Проектные каналы (ObservabilityNotificationChannel) — позволяют настраивать доставку уведомлений в рамках конкретного проекта. Доступны в веб-интерфейсе Deckhouse в соответствующем проекте → «Мониторинг» → «Настройка уведомлений» → «Каналы уведомлений».

• Общедоступные (propagated) каналы (ClusterObservabilityPropagatedNotificationChannel) — создаются на уровне кластера и автоматически становятся доступными во всех проектах для доставки уведомлений. Для создания используется ресурс ClusterObservabilityPropagatedNotificationChannel или консольная утилита d8.

Настройка HTTP-клиента Webhook-канала

Для каналов с spec.type: Webhook можно дополнительно настроить параметры исходящих HTTP-запросов в spec.webhook.httpConfig.

Доступны 3 взаимоисключающих варианта аутентификации:

• basicAuth;
• authorization;
• oauth2.

Обязательные и опциональные поля

• Обязательное поле для Webhook-канала: spec.webhook.url
• spec.webhook.httpConfig — опциональный блок
• При использовании oauth2 обязательны поля oauth2.clientId и oauth2.tokenUrl

Помимо аутентификации, в httpConfig доступны:

• параметры транспорта (enableHttp2, followRedirects);
• настройки прокси (proxyUrl, noProxy, proxyFromEnvironment, proxyConnectHeader);
• настройки TLS (tlsConfig);
• пользовательские заголовки (httpHeaders).

Для OAuth2 есть два уровня настроек:

• httpConfig.proxy* и httpConfig.tlsConfig применяются к запросам отправки webhook;
• httpConfig.oauth2.proxy* и httpConfig.oauth2.tlsConfig применяются к запросам получения OAuth2-токена.

При использовании полей с файлами (passwordFile, credentialsFile, clientSecretFile) указанные пути должны быть доступны внутри контейнера Alertmanager.

Пример с basicAuth:

apiVersion: observability.deckhouse.io/v1alpha1
kind: ClusterObservabilityNotificationChannel
metadata:
  name: webhook-channel-basic-auth
spec:
  type: Webhook
  webhook:
    url: https://hooks.example/webhook
    httpConfig:
      basicAuth:
        username: notify-user
        password: notify-secret

Пример с authorization:

apiVersion: observability.deckhouse.io/v1alpha1
kind: ClusterObservabilityNotificationChannel
metadata:
  name: webhook-channel-authorization
spec:
  type: Webhook
  webhook:
    url: https://hooks.example/webhook
    httpConfig:
      authorization:
        type: Bearer
        credentials: opaque-token

Пример с oauth2:

apiVersion: observability.deckhouse.io/v1alpha1
kind: ClusterObservabilityNotificationChannel
metadata:
  name: webhook-channel-oauth2
spec:
  type: Webhook
  webhook:
    url: https://hooks.example/webhook
    httpConfig:
      oauth2:
        clientId: my-client
        clientSecret: my-secret
        tokenUrl: https://idp.example/token
        scopes:
          - read
          - write
        endpointParams:
          audience: myapp

Правила уведомлений

Правила уведомлений позволяют определить, по какому каналу должны отправляться уведомления для алерта (или группы алертов).

Отключение уведомлений

В ситуациях, когда уведомления ожидаются заранее (например, при плановых работах или тестировании), модуль observability позволяет отключить отправку уведомлений для алертов, соответствующих заданным условиям.

Алерты

Модуль observability обеспечивает разграничение прав доступа к алертам уровня кластера и проектов, а также позволяет просматривать список активных и завершённых алертов.

Активные алерты разделяются по уровню критичности:

• критические (critical, S1–S3);
• предупреждающие (warning, S4–S6);
• информационные (info, S7–S9).

При просмотре алерта пользователь может увидеть общую информацию, лейблы, аннотации и график.

Виды алертов

Поддерживаются два типа алертов:

Описание видов алертов:

• Системные алерты (ClusterObservabilityAlerts) — относятся к компонентам кластера DKP. Полный список активных и завершенных системных алертов доступен в веб-интерфейсе Deckhouse в разделе «Система» → «Управление системой» → «Мониторинг» → «Активные алерты».

• Проектные алерты (ObservabilityAlerts) — относятся к ресурсам конкретного проекта (неймспейса). Полный список активных и завершенных проектных алертов доступен в веб-интерфейсе Deckhouse в соответствующем проекте → «Мониторинг» → «Активные алерты».

Алерты DeadMansSwitch и PrometheusUnavailable

DeadMansSwitch

DeadMansSwitch — это служебный алерт, который срабатывает непрерывно, тем самым подтверждая нормальную работу Prometheus и всего пайплайна доставки алертов.

Если DeadMansSwitch перестает поступать, начинает срабатывать алерт PrometheusUnavailable.

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

Чтобы не засорять список алертов, DeadMansSwitch скрыт из вывода команды d8 k get clusterobservabilityalerts (list/watch). Чтобы получить его напрямую, используйте следующую команду:

d8 k get clusterobservabilityalert deadmansswitch

Отключение этого алерта не рекомендуется, но при необходимости это можно сделать вручную с помощью параметра deadMansSwitch.enabled в настройках модуля.

При ручном отключении алерт PrometheusUnavailable не создается.

PrometheusUnavailable

PrometheusUnavailable (ранее — MissingDeadMansSwitch) — это алерт, который срабатывает, если DeadMansSwitch не поступает более 2 минут.

Это указывает на проблему в пайплайне доставки алертов. Возможные причины:

• недоступен Prometheus;
• нарушено взаимодействие между Prometheus и Alertmanager;
• иная проблема, препятствующая отправке алертов.

Алерт PrometheusUnavailable является системным и отображается как в веб-интерфейсе Deckhouse, так и в выводе команды d8 k get clusterobservabilityalerts.