Кастомные дашборды и алерты

Что нужно знать перед уроком

M10 урок 1 — сбор метрик. Этот урок разбирает, как эти метрики визуализировать в Grafana и превратить в алерты.

Теория

GrafanaDashboardDefinition — legacy-способ, JSON-дашборд инлайн

Исторический способ добавления кастомного дашборда — Custom Resource GrafanaDashboardDefinition, содержащий JSON-описание дашборда Grafana прямо внутри YAML-манифеста (обычно как отдельный ConfigMap или CRD, куда встраивается экспортированный из Grafana JSON). Этот способ по-прежнему работает, но считается менее удобным для сопровождения — JSON-дашборд трудно читать и версионировать построчно при code review.

Новый способ — модуль observability

Прямой преемник GrafanaDashboardDefinition для самих дашбордов — ObservabilityDashboard (namespaced-ресурс, доступный Application-разработчику) / ClusterObservabilityDashboard (cluster-wide, для системных дашбордов). Метаданные, которые у GrafanaDashboardDefinition передавались через поля spec (folder и подобные), теперь задаются аннотациями:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

apiVersion: observability.deckhouse.io/v1alpha1
kind: ObservabilityDashboard
metadata:
  name: {{.Application.Instance.Name}}-dashboard
  namespace: {{.Release.Namespace}}
  annotations:
    metadata.deckhouse.io/category: "Apps"
    metadata.deckhouse.io/title: "Umami"
spec:
  definition: |
    {
      "title": "Umami",
      "panels": []
    }

Родственная, но отдельная возможность того же модуля — recording- и alerting-правила через ClusterObservabilityMetricsRulesGroup (cluster-wide правила в системных namespace) / ObservabilityMetricsRulesGroup (namespaced-вариант, доступный обычному Application-разработчику в своём namespace):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: observability.deckhouse.io/v1alpha1
kind: ClusterObservabilityMetricsRulesGroup
metadata:
  name: {{.Application.Instance.Name}}-custom-metrics
spec:
  interval: 1m
  rules:
    - record: umami_active_sessions_total
      expr: |
        sum(umami_sessions{namespace="{{.Release.Namespace}}"}) by (namespace)

Модуль observability в целом предоставляет более широкие и структурированные возможности, чем разрозненные legacy-механизмы: управление дашбордами, alerting/recording-правилами, настройку каналов уведомлений и политик маршрутизации, просмотр активных алертов и истории их разрешения, а также подключение собственных источников данных.

Recording rules vs alerting rules

record-правила (как в примере выше) предварительно вычисляют и сохраняют результат PromQL-запроса под новым именем метрики — полезно для сложных, часто используемых запросов (избегает повторного вычисления при каждом обращении дашборда/алерта) и для создания метрик, удобных для последующего использования в HPA (M10 урок 4). alert-правила определяют условие срабатывания уведомления, включая for (сколько времени условие должно выполняться, прежде чем алерт перейдёт в состояние firing, а не pending) и annotations/labels для передаваемого в Alertmanager контекста.

Каналы уведомлений: что доступно Application-разработчику, а что — администратору кластера

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: deckhouse.io/v1alpha1
kind: CustomAlertmanager
metadata:
  name: telegram
spec:
  type: Internal
  internal:
    receivers:
      - name: telegram
        telegramConfigs:
          - botToken:
              name: telegram-bot-secret
              key: token
            chatID: -30490XXXXX
    route:
      groupBy: [job]
      groupInterval: 5m
      groupWait: 30s
      receiver: telegram
      repeatInterval: 12h

CustomAlertmanager (настройка каналов — Telegram/Slack/email/webhook, маршрутизация по severity) — это, как правило, cluster-wide ресурс, настраиваемый администратором кластера, а не отдельным Application-разработчиком в своём namespace: единый Alertmanager обслуживает алерты со всего кластера, и произвольное добавление собственных каналов уведомлений каждым разработчиком привело бы к хаосу маршрутизации. Роль Application-разработчика — правильно сформулировать alert-правило (через ObservabilityMetricsRulesGroup в своём namespace) с корректными labels.severity, полагаясь на то, что администратор кластера уже настроил маршрутизацию по этим лейблам к нужным получателям.

Частые ошибки и подводные камни

• Пытаться настроить собственный CustomAlertmanager из namespace Application. Это, как правило, вне зоны ответственности и прав обычного разработчика приложения — конфигурация каналов уведомлений централизована на уровне кластера.
• Использовать JSON GrafanaDashboardDefinition для новых дашбордов вместо ObservabilityDashboard/ClusterObservabilityDashboard. Legacy-способ считается устаревшим, дашборд через него доступен в Grafana только на чтение (нельзя редактировать прямо в браузере), а поддержка самого механизма планируется к удалению в будущих версиях платформы.
• Не устанавливать for в alert-правиле. Без for алерт срабатывает мгновенно при любом кратковременном пересечении порога, что приводит к «шумным» ложным срабатываниям при естественных кратковременных всплесках метрики.

Практика в кластере

1
2
3

d8 k get observabilitydashboard,clusterobservabilitydashboard -A
d8 k get clusterobservabilitymetricsrulesgroup,observabilitymetricsrulesgroup -A
d8 k -n d8-monitoring get customalertmanager

Изучите существующую конфигурацию CustomAlertmanager в кластере (если администратор её настроил) и определите, какие лейблы severity нужно использовать в собственных alert-правилах для корректной маршрутизации.

Практика разработки

Добавьте ObservabilityMetricsRulesGroup в пакет Umami с recording-правилом для агрегированной метрики активных сессий и alert-правилом, срабатывающим при недоступности приложения дольше 5 минут (for: 5m), корректно проставив labels.severity для маршрутизации, а также ObservabilityDashboard с базовым дашбордом, визуализирующим эту метрику.

Шпаргалка команд урока

1
2

d8 k get observabilitydashboard -A
d8 k get clusterobservabilitymetricsrulesgroup -A

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — Observability в Deckhouse
• Deckhouse — Дашборды
• Deckhouse — Интеграции алертов

Статьи и блоги

• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Deckhouse Prom++: как мы посадили Prometheus на RAM-диету — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M10.01 — Мониторинг своего приложения.
• Следующий урок: M10.03 — Логи приложения.

✓ Урок пройден — все вопросы самопроверки отвечены верно