Использование 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
2reciprocity
2022-01-13 05:00:32
<strong>3educational</strong>
gay chat ohio
2022-01-14 15:02:42
<strong>arab friends gay webcam chat https://bjsgaychatroom.info/</strong>
gay dating websites for kids
2022-01-14 16:48:21
<strong>gay nmale dating sites in southern california https://gaypridee.com/</strong>
gay local chat
2022-01-14 20:22:43
<strong>gay chat roulette https://gaytgpost.com/</strong>
free gay radom ewb chat
2022-01-14 22:35:38
<strong>snap chat gay boy dick https://gay-buddies.com/</strong>
best free gay dating sites
2022-01-15 15:47:09
<strong>gay dating simulator https://speedgaydate.com/</strong>
Яндекс.Метрика