Документация Grafana Документация GlaberGraph Оповещения Примеры Dynamic labels

Example of dynamic labels in alert instances

Метки (labels) необходимы для масштабирования вашей системы оповещений. Они определяют метаданные, такие как severity, team, category или environment, которые вы можете использовать для маршрутизации оповещений.

Метку, например severity="critical", можно задать статически в конфигурации правила оповещения или динамически на основе значения запроса, например текущего свободного места на диске. Динамические метки корректируют значения меток во время выполнения, позволяя повторно использовать одно и то же правило оповещения в разных сценариях.

В этом примере показано, как определять динамические метки на основе значений запроса, а также ключевое поведение, которое следует учитывать при их использовании.

Сначала важно понять, как Grafana Alerting трактует метки.

Alert instances are defined by labels

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

Это называется многомерными оповещениями: одно правило, много экземпляров — по одному на каждый уникальный набор меток.

Например, правило, которое запрашивает использование CPU по хостам, может вернуть несколько серий (или измерений):

• {alertname="ServerHighCPU", instance="prod-server-1" }
• {alertname="ServerHighCPU", instance="prod-server-2" }
• {alertname="ServerHighCPU", instance="prod-server-3" }

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

Полный набор меток экземпляра оповещения может включать:

• Метки из результата запроса (например, instance)
• Автоматически генерируемые метки (например, alertname)
• Пользовательские метки из конфигурации правила

User-defined labels

Как показано ранее, экземпляры оповещений автоматически включают метки из результата запроса, такие как instance или job. Чтобы добавить больше контекста или управлять маршрутизацией оповещений, вы можете определить пользовательские метки в конфигурации правила оповещения:

Пользовательские метки могут быть:

• Фиксированными метками: Они имеют одинаковое значение для каждого экземпляра оповещения. Их часто используют для включения общих метаданных, например принадлежности команде.

• Шаблонными метками: Они вычисляют свои значения на основе результата запроса во время оценки.

Templated labels

Шаблонные метки вычисляют свои значения динамически на основе результата запроса. Это позволяет значению метки различаться для каждого экземпляра оповещения.

Используйте шаблонные метки, чтобы вносить дополнительный контекст в оповещения. Синтаксис и варианты использования см. в разделе Шаблоны аннотаций и меток.

Вы можете определять шаблонные метки, которые выдают:

• Фиксированное значение для каждого экземпляра оповещения.
• Динамическое значение для каждого экземпляра оповещения, изменяющееся в зависимости от последнего результата запроса.

Fixed values per alert instance

Вы можете использовать известное значение метки, чтобы обогатить оповещение дополнительными метаданными, отсутствующими в существующих метках. Например, вы можете сопоставить метку instance с меткой env, представляющей среду развёртывания:

Go Copy

{{- if eq $labels.instance "prod-server-1" -}}production
{{- else if eq $labels.instance "stag-server-1" -}}staging
{{- else -}}development
{{- end -}}

Это создаёт экземпляры оповещений, такие как:

• {alertname="ServerHighCPU", instance="prod-server-1", env="production"}
• {alertname="ServerHighCPU", instance="stag-server-1", env="staging"}

В этом примере метка env фиксирована для каждого экземпляра оповещения и не изменяется в течение его жизненного цикла.

Dynamic values per alert instance

Вы можете определить метку, значение которой зависит от числового результата запроса, сопоставляя его с заранее определённым набором вариантов. Это полезно для представления уровней severity в пределах одного правила оповещения.

Вместо определения трёх отдельных правил, таких как:

• CPU ≥ 90 → severity=critical
• CPU ≥ 80 → severity=warning
• CPU ≥ 70 → severity=minor

Вы можете определить одно правило и назначать severity динамически с помощью шаблона:

Go Copy

{{/* $values.B.Value refers to the numeric result from query B */}}
{{- if gt $values.B.Value 90.0 -}}critical
{{- else if gt $values.B.Value 80.0 -}}warning
{{- else if gt $values.B.Value 70.0 -}}minor
{{- else -}}none
{{- end -}}

Этот шаблон позволяет выражать несколько сценариев оповещения в одном правиле, при этом маршрутизируя на основе значения метки severity.

Example overview

В предыдущем шаблоне severity вы можете задать условие оповещения как $B > 70, чтобы предотвратить срабатывание при severity=none, и затем использовать метку severity для маршрутизации различных экземпляров оповещений к разным contact points.

Например, настройте политику уведомлений, которая сопоставляется с alertname="ServerHighCPU", со следующими дочерними политиками:

• severity=critical → эскалация в решение для реагирования на инциденты и управления ими (IRM).
• severity=warning → отправка в канал команды в Slack.
• severity=minor → отправка в очередь несрочных задач или дашборд только с логами.

Итоговый поток оповещений может выглядеть так:

Такая конфигурация оповещений позволяет вам:

• Использовать одно правило для нескольких уровней severity.
• Маршрутизировать оповещения динамически, используя значение метки.
• Упростить поддержку правил оповещения и избежать дублирования.

Однако динамические метки могут приводить к неожиданному поведению, когда значения меток изменяются. В следующем разделе это объясняется.

Caveat: a label change affects a distinct alert instance

Помните: экземпляры оповещений определяются их метками.

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

Вот что происходит, если severity изменяется с minor на warning:

1. Экземпляр с severity="minor" исчезает → он становится отсутствующей серией (missing series).
2. Появляется новый экземпляр с severity="warning" → он начинает с нуля.
3. После двух оценок без данных экземпляр minor разрешается и удаляется.

Пример последовательности:

Подробнее об этом поведении см. в разделе Устаревшие экземпляры оповещений.

В этом примере оповещения minor и warning, вероятно, представляют одну и ту же основную проблему, но Grafana трактует их как отдельные экземпляры оповещений. В результате этот сценарий генерирует два уведомления о срабатывании и два уведомления о разрешении — по одному для каждого экземпляра.

Это поведение важно учитывать, когда значения динамических меток часто изменяются.

Оно может приводить к множеству уведомлений о срабатывании и разрешении за короткие интервалы, что приводит к шумным и запутанным уведомлениям.

Try it with TestData

Вы можете воспроизвести этот сценарий с помощью источника данных TestData, чтобы имитировать нестабильный сигнал — например, мониторинг шумного датчика.

Эта конфигурация воспроизводит «дребезг» меток и показывает, как значения динамических меток влияют на поведение экземпляров оповещений.

1. Добавьте источник данных TestData через меню Connections.

2. Создайте правило оповещения.

   Перейдите в Alerting → Alert rules и нажмите New alert rule.

3. Имитируйте запрос ($A), который возвращает шумный сигнал.

   Выберите TestData в качестве источника данных и настройте сценарий.

   • Scenario: Random Walk
   • Series count: 1
   • Start value: 51
   • Min: 50, Max: 100
   • Spread: 100 (обеспечивает большие изменения между последовательными точками данных)

4. Добавьте выражение.

   • Type: Reduce
   • Input: A
   • Function: Last (чтобы получить самое последнее значение)
   • Name: B

5. Определите условие оповещения.

   Используйте порог, например $B >= 50 (он всегда срабатывает).

6. Нажмите Edit Labels, чтобы добавить динамическую метку.

   Создайте новую метку severity и задайте её значение следующим образом:

   Go Copy

   {{/* $values.B.Value refers to the numeric result from query B */}}
   {{- if gt $values.B.Value 90.0 -}}P1
   {{- else if gt $values.B.Value 80.0 -}}P2
   {{- else if gt $values.B.Value 70.0 -}}P3
   {{- else if gt $values.B.Value 60.0 -}}P4
   {{- else if gt $values.B.Value 50.0 -}}P5
   {{- else -}}none
   {{- end -}}

7. Настройте поведение оценки.

   Задайте короткий интервал оценки (например, 10s), чтобы быстро наблюдать дребезг меток и переходы экземпляров оповещений в истории.

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

   В разделе Configure notifications включите Advanced options.
   Нажмите Preview routing и проверьте значение метки severity:

9. Наблюдайте изменения состояния оповещений.

   Нажмите Save rule and exit и откройте представление истории оповещений, чтобы увидеть, как изменения severity влияют на состояние различных экземпляров оповещений.

   Tip

   Вы можете изучить этот пример оповещений в Grafana Play.

   Откройте пример, чтобы увидеть результаты оценки оповещений, созданные экземпляры оповещений, временную шкалу истории оповещений и сведения о правилах оповещения.

Considerations

Динамические метки позволяют повторно использовать одно правило оповещения в нескольких сценариях эскалации — но они также добавляют сложность. Когда значение метки зависит от шумной метрики и часто изменяется, это может приводить к дребезгу экземпляров оповещений и избыточным уведомлениям.

Такие оповещения часто требуют настройки, чтобы оставаться надёжными, и выигрывают от постоянного пересмотра. Чтобы извлечь максимум из этого шаблона, учитывайте следующее:

• Настраивайте параметры оценки и запросы для стабильности

  Увеличьте интервал оценки и период pending, чтобы снизить частоту изменений состояния. Кроме того, рассмотрите сглаживание метрик с помощью функций, таких как avg_over_time, чтобы уменьшить дребезг.

• Используйте более широкие полосы порогов

  Определяйте более широкие диапазоны в логике шаблона меток, чтобы предотвратить переключение меток из-за небольших изменений значений.

• Отключайте уведомления о разрешении

  Когда метки часто изменяются и оповещения быстро разрешаются, вы можете уменьшить количество уведомлений, отключив уведомления о разрешении на уровне contact point.

• Отключайте настройку оценки Missing series

  Настройка оценки Missing series (по умолчанию: 2) определяет, сколько интервалов без данных допускается до разрешения экземпляра. Рассмотрите возможность её отключения, если она не нужна для вашего случая, так как она может усложнить отладку оповещений.

• Сохраняйте контекст между связанными оповещениями

  Убедитесь, что метаданные оповещений содержат достаточно информации, чтобы помочь сопоставить связанные оповещения во время расследования.

• Используйте отдельные правила оповещения и статические метки, когда это проще

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

Learn more

Ниже приведён список дополнительных ресурсов, связанных с этим примером:

• Пример многомерных оповещений — Изучите, как Grafana создаёт отдельные экземпляры оповещений для каждого уникального набора меток.
• Метки — Узнайте о различных типах меток и о том, как они определяют экземпляры оповещений.
• Шаблонные метки в правилах оповещения — Используйте шаблонизацию для динамического задания значений меток на основе результатов запросов.
• Устаревшие экземпляры оповещений — Поймите, как Grafana разрешает и удаляет устаревшие экземпляры оповещений.
• Обработка отсутствующих данных — Узнайте, как Grafana различает отсутствующие серии и NoData.
• Политики уведомлений и маршрутизация — Создавайте несколько политик уведомлений для маршрутизации оповещений на основе значений меток, таких как severity или team.
• Пример динамических меток в Grafana Play — Просмотрите этот пример в Grafana Play, чтобы изучить экземпляры оповещений и переходы состояний с динамическими метками.