Использование alert_relabel_configs

Переназначение меток в Prometheus используется чаще всего в секции scrape_configs — после списка таргетов идет опция relabel_configs. Для большинства хорошо понятно как она работает — есть исходная метрика (source_labels), есть целевая (target_label). Где-то в «середине» напрямую или с ипользованием регулярок идет извлечение значения, его изменение и сохранение в целевой метке.

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

Использование alert_relabel_configs

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

Возьмем в качестве примера ситуацию с простым алертом:

Его важность — critical — и например в алертменеджере для алертов с такой важностью предусмотрен срочный звонок сисадминам. Но что, если есть не особо важные хосты, возможно для тестирования, либо просто с низкоприоритетной нагрузкой, по которым срочно звонить дежурным не надо? Как их исключить? Варианты есть.

Можно просто добавить имя хоста в исключения в алерте напрямую:

Минусы очевидны — представьте, если у вас таких хостов 10 или 1000. Более предпочтительным вариантом будет выставить в списке таргетов для таких хостов определенную метку (см. severity_rewrite):

Далее в алерте делаем обработку этого лейбла:

Тогда придется написать второй алерт с другим значением лейбла (или с его отсутствием), что усложнит конфигурацию. Гораздо лучше добавить сложное условие в severity, тогда и алерты плодит не придется:

Уже лучше, но неужели вы так будете делать для каждого алерта? Получается слишком громоздко, да и велико влияние человеческого фактора.

Есть возможность переопределять значение лейбла централизованно в секции alerting. Для этого нужно использовать опцию alert_relabel_configs. Выглядит это следующим образом:
alerting:

Тут мы склеиваем два лейбла (разделитель по умолчанию — «;«), после чего проверяем регуляркой значение обоих и если оно совпадает с паттерном, то выполняем изменение лейбла severity.

Примечание: алерты тоже являются метриками (вы можете подергать их запросом {__name__=~»ALERTS.*»}, но управлять их лейблами вы не сможете из секции scrape_configs, это можно сделать только из alert_relabel_configs.

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

Но в алертменеджере будет ожидаемо severity=»warning»:

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

comments powered by HyperComments
Яндекс.Метрика