Переназначение меток в Prometheus используется чаще всего в секции scrape_configs – после списка таргетов идет опция relabel_configs. Для большинства хорошо понятно как она работает – есть исходная метрика (source_labels), есть целевая (target_label). Где-то в “середине” напрямую или с ипользованием регулярок идет извлечение значения, его изменение и сохранение в целевой метке.
Тем не менее есть и ряд других мест, где релейблинг может оказаться очень полезным. В этой статье я напомню о них.
Использование alert_relabel_configs
Как может быть понятно из названия статьи, речь пойдет именно о alert_relabel_configs. Однако релейблинг очень мощный инструмент управления метриками, встречающийся и в других секциях конфигурации 1, имея при этом везде одинаковый синтаксис.
Возьмем в качестве примера ситуацию с простым алертом:
|
1 2 3 4 5 6 7 8 |
- alert: instance_down expr: up == 0 for: 1m labels: severity: critical annotations: summary: Instance scrape failed description: Check if the host is down, try ping or ssh directly on the host |
Его важность – critical – и например в алертменеджере для алертов с такой важностью предусмотрен срочный звонок сисадминам. Но что, если есть не особо важные хосты, возможно для тестирования, либо просто с низкоприоритетной нагрузкой, по которым срочно звонить дежурным не надо? Как их исключить? Варианты есть.
Можно просто добавить имя хоста в исключения в алерте напрямую:
|
1 |
expr: up{instance!="hostname.domain.local"} == 0 |
Минусы очевидны – представьте, если у вас таких хостов 10 или 1000. Более предпочтительным вариантом будет выставить в списке таргетов для таких хостов определенную метку (см. severity_rewrite):
|
1 2 3 4 5 6 |
static_configs: - targets: - https://staging.company.tld labels: team: some_team severity_rewrite: warning |
Далее в алерте делаем обработку этого лейбла:
|
1 |
expr: up{severity_rewrite!="warning"} == 0 |
Тогда придется написать второй алерт с другим значением лейбла (или с его отсутствием), что усложнит конфигурацию. Гораздо лучше добавить сложное условие в severity, тогда и алерты плодит не придется:
|
1 |
severity: '{{if eq $labels.severity_rewrite "warning"}}warning{{else}}critical{{end}}' |
Уже лучше, но неужели вы так будете делать для каждого алерта? Получается слишком громоздко, да и велико влияние человеческого фактора.
Есть возможность переопределять значение лейбла централизованно в секции alerting. Для этого нужно использовать опцию alert_relabel_configs. Выглядит это следующим образом:
alerting:
|
1 2 3 4 5 6 |
alerting: alert_relabel_configs: - source_labels: [severity_rewrite,severity] regex: warning;critical replacement: warning target_label: severity |
Тут мы склеиваем два лейбла (разделитель по умолчанию – “;“), после чего проверяем регуляркой значение обоих и если оно совпадает с паттерном, то выполняем изменение лейбла severity.
Помните, что метки меняются только перед отправкой в алертменеджер, поэтому в самом прометее вы увидите значение severity, которое указано в правиле алерта:
Но в алертменеджере будет ожидаемо severity=”warning”:
В итоге все алерты для данного хоста будут иметь пониженный приоритет. Сами правила алертинга останутся неизменными, что несомненно огромный плюс. На этом все.
Notes:
