Документацияbreadcrumb arrow Grafanabreadcrumb arrow Документация GlaberGraphbreadcrumb arrow Оповещенияbreadcrumb arrow Дополнительная конфигурацияbreadcrumb arrow Соображения по производительности и ограничения

Соображения по производительности и ограничения

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

Вычисление правил оповещений потребляет RAM и CPU для вычисления результата запроса оповещения, а также сетевые ресурсы для отправки уведомлений об оповещениях и записи результатов в базу данных SQL Grafana. Конфигурация отдельных правил оповещений влияет на потребление ресурсов и, следовательно, на максимальное количество правил, которое может поддерживать данная конфигурация.

Следующий раздел содержит список соображений по производительности оповещений.

  • Соображение о частоте вычисления правил. Свойство “Evaluate Every” правила оповещения управляет частотой вычисления правила. Рекомендуется использовать наименьшую приемлемую частоту вычисления, чтобы поддерживать больше одновременных правил.
  • Кардинальность набора результатов правила. Например, предположим, вы отслеживаете ошибки ответов API для каждого пути API на каждой виртуальной машине в вашем парке. Этот набор имеет кардинальность n количества путей, умноженного на v количества ВМ. Вы можете уменьшить кардинальность набора результатов — возможно, отслеживая ошибки на ВМ вместо каждого пути на ВМ.
  • Соображение о сложности запроса оповещения. Запросы, которые источники данных могут обработать и ответить на них быстро, потребляют меньше ресурсов. Хотя это соображение менее важно, чем другие перечисленные выше, если вы максимально их уменьшили, анализ производительности отдельных запросов может иметь значение.

Каждое вычисление правила оповещения генерирует набор экземпляров оповещений; по одному на каждый элемент набора результатов. Состояние всех экземпляров записывается в таблицу alert_instance в базе данных SQL Grafana. Такое количество операций с интенсивной записью может вызывать проблемы при использовании SQLite.

Grafana Alerting предоставляет метрику grafana_alerting_rule_evaluations_total, которая считает количество вычислений правил оповещений. Чтобы получить представление о влиянии вычислений правил на ваш экземпляр Grafana, вы можете наблюдать за скоростью вычислений и сравнивать её с потреблением ресурсов. В совместимой с Prometheus базе данных вы можете использовать запрос rate(grafana_alerting_rule_evaluations_total[5m]), чтобы вычислить скорость за 5-минутные окна времени. Важно помнить, что это не полная картина вычисления правил. Например, нагрузка распределена неравномерно, если у вас есть правила, вычисляемые каждые 10 секунд, и другие каждые 30 минут.

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

Ограниченная поддержка источников правил

Grafana Alerting может извлекать правила оповещений и recording-правила, хранящиеся в большинстве доступных источников данных, совместимых с Prometheus, Loki, Mimir и Alertmanager.

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

Поддержка версий Prometheus

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

Например, если текущая версия Prometheus — 2.31.1, поддерживается >= 2.29.0.

Grafana Alertmanager может принимать только Grafana managed оповещения

Grafana нельзя использовать для приёма внешних оповещений. Вы можете отправлять оповещения в Grafana Alertmanager только с помощью Grafana managed оповещений.

У вас есть возможность отправлять Grafana-managed оповещения во внешний Alertmanager; эту опцию можно найти на вкладке Admin на странице Alerting.

Дополнительные сведения см. в этом issue на GitHub.

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

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

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

Warning

Более ранние версии Grafana записывали состояние экземпляров оповещений в базу данных несжатыми, по одной строке на экземпляр, и позволяли включить сжатое хранение с помощью feature toggle alertingSaveStateCompressed. Grafana 13.2 полностью удаляет этот feature toggle и путь несжатого хранения.

Если вы обновляетесь с версии Grafana, где вы явно отключили alertingSaveStateCompressed, включите его и дайте Grafana поработать как минимум один цикл вычисления до обновления до Grafana 13.2 или новее. Иначе любое состояние оповещений, всё ещё хранящееся в старом несжатом формате, не будет прочитано после обновления. Это не вызывает потери данных за пределами самого состояния оповещений: Grafana повторно вычисляет каждое правило и пересоздаёт состояние экземпляров с нуля, но сразу после обновления вы можете увидеть кратковременный разовый пробел в истории оповещений и текущем состоянии.

Периодическое сохранение состояния

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

Включите feature toggle alertingSaveStatePeriodic, чтобы сохранять состояния оповещений с интервалом, заданным state_periodic_save_interval, вместо после каждого вычисления правила. Grafana группирует все экземпляры оповещений по UID правила и сжимает их вместе для эффективного хранения.

По умолчанию Grafana сохраняет состояния каждые 5 минут и при каждом завершении работы. Обратите внимание, что state_periodic_save_batch_size и state_periodic_save_jitter_enabled здесь не применяются, так как Grafana группирует экземпляры по UID правила, а не по пакету.

ini 
[unified_alerting]
state_periodic_save_interval = 1m

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

Лимит на количество результатов на правило оповещения

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

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

query evaluation returned too many results: 12345 (limit: 10000)

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

В самостоятельно управляемой Grafana задайте этот лимит с помощью опции alerting_rule_evaluation_results в секции [quota]. Значение по умолчанию — -1 (без ограничений). В Grafana Cloud этот лимит управляется Grafana Labs.

Чтобы устранить ошибку, уменьшите кардинальность набора результатов правила:

  • Агрегируйте запрос, чтобы он возвращал меньше серий. Например, суммируйте или усредняйте по меньшему числу меток.
  • Добавьте фильтры меток, чтобы запрос возвращал только те серии, по которым нужно оповещать.
  • Разделите одно правило высокой кардинальности на несколько правил с более узкими запросами.

Миграции правил оповещений для Grafana 11.6.0

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