Документацияbreadcrumb arrow Grafanabreadcrumb arrow Документация GlaberGraphbreadcrumb arrow Оповещенияbreadcrumb arrow Дополнительная конфигурацияbreadcrumb arrow Метамониторинг

Meta monitoring

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

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

Чтобы дать вам возможность заниматься мета-мониторингом, Grafana предоставляет предопределённые метрики.

Определите, какие метрики критичны для вашей системы мониторинга (то есть для Grafana), и затем настройте, как вы хотите их отслеживать.

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

  1. Необязательно: создайте дашборд в Grafana, использующий эту метрику на панели (точно так же, как для любого другого типа метрик).
  2. Необязательно: создайте правило оповещения в Grafana, которое регулярно проверяет эту метрику (точно так же, как для любого другого типа правил оповещения).
  3. Необязательно: используйте модуль Explore в Grafana.

Metrics for Grafana-managed alerts

Для мета-мониторинга Grafana-managed оповещений вы можете собирать два типа метрик в экземпляре Prometheus:

  • Метрика истории состояний (GRAFANA_ALERTS) — экспортируется Grafana Alerting как часть истории состояний оповещений.

  • Собираемые метрики (scraped metrics) — экспортируются конечной точкой /metrics в Grafana для мониторинга активности и производительности системы оповещений.

Вам нужен сервер, совместимый с Prometheus, для сбора и хранения этих метрик.

GRAFANA_ALERTS metric

Если вы настроили Prometheus для истории состояний оповещений, Grafana записывает изменения состояния оповещений в метрику ALERTS:

GRAFANA_ALERTS{alertname="", alertstate="", grafana_alertstate="", grafana_rule_uid="", <additional alert labels>}

Эта метрика GRAFANA_ALERTS совместима с метрикой ALERTS, используемой Prometheus Alerting, и включает две дополнительные метки:

  1. Новую метку grafana_rule_uid для UID правила Grafana.
  2. Новую метку grafana_alertstate для состояния оповещения Grafana, которое немного отличается от эквивалентного состояния Prometheus, включённого в метку alertstate.

Метки оповещений автоматически преобразуются перед записью в Prometheus для обеспечения совместимости. Prometheus требует, чтобы имена меток начинались с буквы или подчёркивания (_) и содержали только буквы, цифры или дополнительные подчёркивания. Недопустимые символы заменяются при преобразовании. Например, 1my-label становится _my_label.

Состояние Grafana alertstate grafana_alertstate
Alerting firing alerting
Recovering firing recovering
Pending pending pending
Error firing error
NoData firing nodata
Normal (метрика не выдаётся) (метрика не выдаётся)

Затем вы можете запрашивать эту метрику как любую другую метрику Prometheus:

firing-alerts 
GRAFANA_ALERTS{grafana_alertstate="alerting"}
recovering-alerts 
GRAFANA_ALERTS{grafana_alertstate="recovering"}
critical-alerts-in-pending 
GRAFANA_ALERTS{grafana_alertstate="pending", severity="critical"}

Scraped metrics

Чтобы собирать метрики Alerting через scraping, настройте Prometheus на сбор метрик из Grafana.

YAML 
- job_name: grafana
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  static_configs:
    - targets:
        - grafana:3000

Правитель Grafana (ruler), отвечающий за оценку правил оповещения, и Grafana Alertmanager, отвечающий за отправку уведомлений о сработавших и разрешившихся оповещениях, предоставляют ряд метрик, позволяющих наблюдать за ними.

grafana_alerting_alerts

Эта метрика — счётчик, показывающий количество оповещений в состояниях normal, pending, alerting, nodata и error. Например, вы можете создать оповещение, которое срабатывает, когда grafana_alerting_alerts{state="error"} больше 0.

grafana_alerting_schedule_alert_rules

Эта метрика — gauge, показывающая количество запланированных правил оповещения. Правило оповещения считается запланированным, если оно не приостановлено, и значение этой метрики должно соответствовать общему количеству неприостановленных правил оповещения в Grafana.

grafana_alerting_schedule_periodic_duration_seconds_bucket

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

grafana_alerting_schedule_query_alert_rules_duration_seconds_bucket

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

grafana_alerting_scheduler_behind_seconds

Эта метрика — gauge, показывающая количество секунд, на которое планировщик отстаёт от того, где он должен быть. Это число увеличивается, если schedule_periodic_duration_seconds больше 10 секунд, и уменьшается, когда оно меньше 10 секунд. Наименьшее возможное значение этой метрики — 0.

grafana_alerting_notification_latency_seconds_bucket

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

grafana_alerting_state_history_writes_failed_total

Эта метрика — счётчик, показывающий количество неудачных записей в настроенный бэкенд истории состояний оповещений. Она включает метку backend для различения разных бэкендов (например, loki или prometheus).

Например, вы можете создать оповещение, которое срабатывает, когда grafana_alerting_state_history_writes_failed_total{backend="prometheus"} больше 0, чтобы обнаруживать сбои удалённой записи Prometheus.

Logs for Grafana-managed alerts

Если вы настроили Loki для истории состояний оповещений, логи, связанные с изменениями состояний Grafana-managed оповещений, хранятся в источнике данных Loki.

Вы можете использовать Grafana Explore и редактор запросов Loki для поиска изменений состояний оповещений.

basic-query 
{from="state-history"} | json
additional-filters 
{from="state-history"} | json | previous=~"Normal.*" | current=~"Alerting.*"
failing-rules 
{from="state-history"} | json | current=~"Error.*"

В представлении Logs вы можете просматривать детали отдельных оповещений, выбирая такие поля, как:

  • previous: предыдущее состояние экземпляра оповещения.
  • current: текущее состояние экземпляра оповещения.
  • ruleTitle: заголовок правила оповещения.
  • ruleID и ruleUID.
  • labels_alertname, labels_new_label и labels_grafana_folder.
  • Другие доступные поля.

Либо вы можете открыть страницу History в Grafana, чтобы визуализировать и фильтровать изменения состояний отдельных оповещений или всех оповещений.

Если вы включили историю уведомлений, вы также можете обратиться к разделу Просмотр истории уведомлений, чтобы просмотреть отправленные уведомления и результаты доставки на вкладке Notifications страницы History.

Metrics for Mimir-managed alerts

Для мета-мониторинга Grafana Mimir-managed оповещений пользователям open source и on-premise нужен сервер Prometheus/Mimir или другая база данных метрик для сбора и хранения метрик, экспортируемых правителем Mimir.

rule_evaluation_failures_total

Эта метрика — счётчик, показывающий общее количество сбоев оценки правил.

Metrics for Alertmanager

Для мета-мониторинга Alertmanager вам нужен сервер Prometheus/Mimir или другая база данных метрик для сбора и хранения метрик, экспортируемых Alertmanager.

Например, если вы используете Prometheus, вам следует добавить scrape_config в Prometheus для сбора метрик из вашего Alertmanager.

YAML 
- job_name: alertmanager
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  follow_redirects: true
  static_configs:
    - targets:
        - alertmanager:9093

Ниже приведён список доступных метрик для Alertmanager.

alertmanager_alerts

Эта метрика — счётчик, показывающий количество активных, подавленных и необработанных оповещений в Alertmanager. Подавленные оповещения — это оповещения, для которых действует silence, а необработанные — это оповещения, которые были отправлены в Alertmanager, но ещё не обработаны.

alertmanager_alerts_invalid_total

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

alertmanager_notifications_total

Эта метрика — счётчик, показывающий, сколько уведомлений отправлено Alertmanager. Метрика использует метку «integration», чтобы показать количество уведомлений, отправленных по интеграции, например email.

alertmanager_notifications_failed_total

Эта метрика — счётчик, показывающий, сколько уведомлений в сумме не удалось доставить. Эта метрика также использует метку «integration», чтобы показать количество неудачных уведомлений по интеграции, например неудачных писем. В большинстве случаев используйте функцию rate, чтобы понять, как часто уведомления не удаётся отправить.

alertmanager_notification_latency_seconds_bucket

Эта метрика — гистограмма, показывающая, сколько времени требуется Alertmanager, чтобы отправить уведомления и чтобы они были приняты принимающим сервисом. Эта метрика использует метку «integration», чтобы показать время по интеграции. Например, вы можете использовать эту метрику, чтобы показать 95-й процентиль задержки отправки писем.

Metrics for Alertmanager in high availability mode

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

alertmanager_cluster_members

Эта метрика — gauge, показывающая текущее количество участников в кластере. Значение этого gauge должно быть одинаковым для всех Alertmanager. Если разные Alertmanager показывают разное количество участников, это указывает на проблему в вашем кластере Alertmanager. Вам следует изучить метрики и логи ваших Alertmanager, чтобы лучше понять, что может идти не так.

alertmanager_cluster_failed_peers

Эта метрика — gauge, показывающая текущее количество отказавших узлов.

alertmanager_cluster_health_score

Эта метрика — gauge, показывающая оценку работоспособности Alertmanager. Меньшие значения лучше, а ноль означает, что Alertmanager работоспособен.

alertmanager_cluster_peer_info

Эта метрика — gauge. Она имеет постоянное значение 1 и содержит метку под названием «peer» с Peer ID каждого известного узла.

alertmanager_cluster_reconnections_failed_total

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