Документация Grafana Документация GlaberGraph Источники данных Prometheus Оповещения

Алертинг Prometheus

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

Общую информацию о Grafana Alerting см. в разделе Grafana Alerting.

Перед началом

Перед созданием алертов с Prometheus убедитесь, что у вас есть:

• Источник данных Prometheus, настроенный в Grafana
• Соответствующие разрешения для создания правил алертинга
• Понимание метрик PromQL, которые вы хотите отслеживать

Типы правил алертинга

Prometheus поддерживает два рабочих процесса алертинга в Grafana:

Создание правила алертинга, управляемого Grafana

Чтобы создать управляемое Grafana правило алертинга с использованием Prometheus:

1. Перейдите в Alerting > Alert rules.
2. Нажмите New alert rule.
3. Введите имя для правила алертинга.
4. Выберите ваш источник данных Prometheus.
5. Напишите запрос PromQL в редакторе запросов.
6. Настройте условие алерта (например, когда последнее значение выше порога).
7. Задайте интервал вычисления и период ожидания (pending period).
8. Настройте уведомления и метки.
9. Нажмите Save rule.

Подробные инструкции см. в разделе Создание управляемого Grafana правила алертинга.

Просмотр правил, управляемых источником данных

Когда в конфигурации источника данных Prometheus включено Manage alerts via Alerting UI, Grafana извлекает и отображает правила алертинга, определённые в Prometheus. Они появляются в интерфейсе Alerting наряду с правилами, управляемыми Grafana, но помечаются как управляемые источником данных.

Для источников данных Prometheus это представление доступно только для чтения. Чтобы изменить эти правила, обновите файлы правил Prometheus напрямую.

Группы вычисления и интервалы

Правила алертинга организованы в группы вычисления. Каждая группа имеет интервал вычисления, определяющий, как часто вычисляются правила в этой группе. Например, интервал вычисления 1m означает, что запрос алерта выполняется каждые 60 секунд.

Период ожидания (pending period) определяет, как долго условие должно быть непрерывно истинным, прежде чем алерт сработает. Например, с интервалом вычисления 1 минута и периодом ожидания 5 минут условие должно быть истинным в течение 5 последовательных вычислений, прежде чем сработать.

Выбирайте интервалы вычисления исходя из вашего случая использования:

• 15s–30s: алерты критической инфраструктуры, где важна быстрая детекция.
• 1m: стандартные алерты мониторинга (рекомендуемое значение по умолчанию).
• 5m: несрочные или шумные метрики, где вы хотите снизить нагрузку вычисления.

Примеры запросов для алертов

В следующих примерах показаны распространённые сценарии алертинга с Prometheus. Каждый пример показывает запрос PromQL и то, как настроить условие алерта.

Алерт по высокому использованию ЦП

Отслеживайте использование ЦП и создавайте алерт, когда оно превышает 90%:

Запрос A:

promql Copy

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[$__rate_interval])) * 100)

Условие: установите порог, чтобы создавать алерт, когда последнее значение A выше 90.

Этот подход отделяет запрос метрики от порога, упрощая последующую корректировку порога без редактирования PromQL.

Алерт по высокому использованию памяти

Отслеживайте использование памяти по узлам:

Запрос A:

promql Copy

(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

Условие: создавайте алерт, когда последнее значение A превышает 85.

Алерт по высокой частоте ошибок

Отслеживайте частоту ошибок HTTP по службам:

Запрос A:

promql Copy

sum(rate(http_requests_total{status=~"5.."}[$__rate_interval])) by (job)
  /
sum(rate(http_requests_total[$__rate_interval])) by (job)
  * 100

Условие: создавайте алерт, когда последнее значение A превышает 5 (что означает частоту ошибок выше 5%).

Алерт о недоступной цели

Отслеживайте, доступны ли цели сбора Prometheus:

Запрос A:

promql Copy

up{job="myservice"}

Условие: создавайте алерт, когда последнее значение A ниже 1.

Алерт, когда метрика исчезает

Используйте absent() для обнаружения момента, когда метрика перестаёт собираться полностью, например, когда служба падает и больше не сообщает метрики:

Запрос A:

promql Copy

absent(up{job="myservice"})

Условие: создавайте алерт, когда последнее значение A равно 1 (функция absent() возвращает 1, когда метрика отсутствует, и ничего, когда метрика существует).

Для обнаружения устаревания за временное окно (метрика существует, но не сообщалась недавно):

promql Copy

absent_over_time(up{job="myservice"}[5m])

Алерт с несколькими условиями (высокая задержка И высокий трафик)

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

Запрос A (задержка P95):

promql Copy

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="api"}[$__rate_interval])) by (le))

Запрос B (частота запросов):

promql Copy

sum(rate(http_requests_total{job="api"}[$__rate_interval]))

Выражение C (Math, объединяющее оба условия):

Copy

$A > 2 && $B > 100

Условие: создавайте алерт, когда C имеет значение (оно возвращает данные только тогда, когда задержка превышает 2 секунды И частота запросов превышает 100 запросов/с).

Правила записи

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

Когда использовать правила записи

• Панели дашборда, которые многократно запрашивают одно и то же дорогостоящее выражение: предварительно вычислите его один раз и запрашивайте результат.
• Правила алертинга по сложным выражениям: упростите запрос алерта, создавая алерт по предварительно агрегированной метрике.
• Агрегации с высокой кардинальностью: сократите тысячи рядов до нескольких предварительно вычисленных рядов.

Настройка правил записи, управляемых Grafana, для Prometheus

1. Включите источник данных как цель правил записи: в конфигурации источника данных Prometheus убедитесь, что переключатель Allow as recording rules target включён (он включён по умолчанию). Это позволяет Grafana записывать результаты правил записи обратно в этот экземпляр.

2. Проверьте доступ на запись: совместимый с Prometheus бэкенд должен поддерживать remote write. Grafana Cloud Metrics (Mimir) и самостоятельно размещённый Mimir поддерживают это изначально. Стандартный Prometheus требует флага --web.enable-remote-write-receiver (Prometheus 2.33+).

3. Создайте правило записи:

   1. Перейдите в Alerting > Alert rules.

   2. Нажмите New alert rule.

   3. Выберите Recording rule в качестве типа правила (в разделе, управляемом Grafana).

   4. Введите выражение PromQL, которое хотите предварительно вычислить:

      promql Copy

      sum(rate(http_requests_total[$__rate_interval])) by (service)

   5. Введите имя метрики для результата (например, service:http_requests:rate5m). Следуйте соглашению об именовании правил записи Prometheus: level:metric:operations.

   6. Выберите Target data source — экземпляр Prometheus, в который записываются результаты.

   7. Задайте интервал вычисления (например, каждую 1 минуту).

   8. Нажмите Save rule.

4. Запросите записанную метрику: после первого вычисления новая метрика становится доступной для дашбордов и алертов:

   promql Copy

   service:http_requests:rate5m{service="api"}

Правила записи с PDC

Если ваш экземпляр Prometheus находится за Private data source connect (PDC), Grafana может записывать результаты правил записи через туннель PDC. Дополнительная конфигурация не требуется, поскольку PDC поддерживает как чтение, так и запись.

Ограничения

• Правила записи требуют, чтобы целевой источник данных поддерживал remote write. Стандартному Prometheus нужен флаг --web.enable-remote-write-receiver.
• Thanos не поддерживает правила записи в качестве цели записи (см. сравнение типов Prometheus).
• Вычисление правил записи использует настроенный интервал вычисления, а не диапазоны времени дашборда. Используйте фиксированный векторный диапазон (например, [5m]) вместо $__rate_interval.

Дополнительную информацию см. в разделе Создание правил записи, управляемых Grafana.

Ограничения

При использовании Prometheus с Grafana Alerting учитывайте следующие ограничения.

Переменные шаблонов не поддерживаются

Запросы алертов не поддерживают переменные шаблонов. Grafana вычисляет правила алертинга на бэкенде без контекста дашборда, поэтому переменные, такие как $instance или $job, не разрешаются.

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

Сложность запроса

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

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

Обработка OAuth-токена различается в Explore и Alerting

При использовании конечных точек Prometheus с аутентификацией OAuth (Google Managed Prometheus, Azure Managed Prometheus) запросы могут успешно выполняться в Explore и на дашбордах, но периодически завершаться неудачно во время вычисления алерта. Это происходит потому, что бэкенд алертинга обрабатывает обновление токена иначе, чем интерактивный путь запроса.

Если вы используете GCP, рассмотрите шаблон datasource-syncer — процесс-сайдкар, который обновляет OAuth-токены и обновляет учётные данные источника данных по расписанию, более короткому, чем время жизни токена.

Подробные шаги по устранению неполадок см. в разделе Ошибки истечения срока действия OAuth-токена.

Правила, управляемые источником данных, доступны только для чтения

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

Настройка состояния алерта при ошибках выполнения

По умолчанию, когда управляемое Grafana правило алертинга сталкивается с ошибкой выполнения или тайм-аутом (таким как сетевой сбой, i/o timeout или временный 502 от Prometheus), правило переходит в состояние Error, что запускает алерт. Это может вызывать ложные тревоги и спам дежурным командам, когда основная проблема — кратковременный перерыв в связности, а не реальное пересечение порога.

Чтобы предотвратить ложные срабатывания из-за временных ошибок, настройте параметр Alert state if execution error or timeout в каждом правиле алертинга:

1. Откройте правило алертинга для редактирования.
2. В разделе условий алерта найдите Alert state if execution error or timeout.
3. Измените значение с Alerting (по умолчанию) на одно из:
   • Keep Last State: алерт сохраняет своё предыдущее состояние (сработавший или нормальный) до успешного вычисления. Это рекомендуемая настройка для большинства правил алертинга Prometheus.
   • OK: алерт устанавливается в нормальное состояние во время ошибки, предотвращая его срабатывание.
4. Нажмите Save rule.

Распространённые временные ошибки, запускающие это поведение, включают:

• sse.dependencyError или sse.dataQueryError в истории состояний алерта
• сообщения «context deadline exceeded» или «i/o timeout»
• ответы HTTP 502 или 500 от сервера Prometheus

Подробнее об устранении этих ошибок см. в разделе Устранение неполадок источника данных Prometheus.

Рекомендации

Следуйте этим рекомендациям при создании алертов Prometheus:

• Настройте обработку состояний ошибок: установите Alert state if execution error or timeout в Keep Last State, чтобы предотвратить ложные тревоги из-за временных ошибок бэкенда.
• Используйте $__rate_interval: при использовании rate() или increase() в запросах алертов используйте $__rate_interval, чтобы гарантировать, что окно диапазона всегда достаточно велико относительно интервала сбора. Grafana разрешает эту переменную на основе интервала вычисления и конфигурации интервала сбора.
• Добавляйте фильтры меток: включайте конкретные сопоставители меток, чтобы сосредоточиться на релевантных данных и улучшить производительность запроса.
• Задавайте реалистичные периоды ожидания: используйте период ожидания, чтобы избежать алертов по кратковременным всплескам. Например, задайте период ожидания 5 минут, чтобы условие должно было сохраняться перед срабатыванием.
• Сначала тестируйте запросы: проверьте, что ваш запрос возвращает ожидаемые результаты в Explore, прежде чем создавать алерт.
• Используйте осмысленные имена: давайте правилам алертинга описательные имена, указывающие, что они отслеживают, и уровень серьёзности.
• Предварительно агрегируйте с помощью правил записи: для сложных или часто вычисляемых выражений создавайте правила записи и создавайте алерты по предварительно агрегированной метрике.
• Используйте absent() для мониторинга доступности: обнаруживайте момент, когда метрики перестают сообщаться, что часто указывает на упавшую или неотвечающую службу.

Если вы сталкиваетесь с ошибками при создании или вычислении правил алертинга, см. раздел Устранение неполадок источника данных Prometheus.