LINUX.ORG.RU
ФорумAdmin

prometheus - посмотреть какие алерты привязаны к хосту

 , ,


0

2

Добрый день. Мы в процессе перехода с nagios на prometheus (по некоторым причинам, не суть важно). В самом начале столкнулся с проблемой - в прометее вообще возможно посмотреть какие алерты привязаны к хосту (кроме как заглядывания в alerts.rules)? Сейчас конфиг нагиоса генерим через самописный скрипт, скрипт запускается в одной из частей роли ансибла (скрипт берет переменные yaml из host_vars для построения конфига) - нам это дает, что мы можем посмотреть какие проверки привязаны к хосту как в ансбиле, так и в веб-интрефейсе нагиоса. Yaml примерно такой:

nagios: [
  "ssh", "exim", "user", "raid", "inode", "mem",
  {"load": {args: ["28.0,24.0,20.0", "30.0,28.0,24.0"]}},
  {certificate_port: {name: "Cert site", args: ["test.ru", 443, 15, 5], rare: 1}},
  {disk: {name: "hdd-var", args: ["15%", "10%", "/dev/mapper/hdd-var"]}},
  {disk: {name: "hdd-root",args: ["15%", "10%", "/dev/mapper/hdd-root"]}},
  {smart: {name: "SMART sda", args: ["ata", "/dev/sda"]}},
  {smart: {name: "SMART sdb", args: ["ata", "/dev/sdb"]}},
  {smart: {name: "SMART sdc", args: ["ata", "/dev/sdc"]}},
  {smart: {name: "SMART sdd", args: ["ata", "/dev/sdd"]}},
  {mailq: {args: [5, 10]}}
]

В прометее хотим добится нечто такого же (просмотр всех проверок, привязанных к хосту), но уйти от этого костыля (питон скрипта, генерирующего конфиг). В веб-интерфейсе прометея на вкладке Alerts можно увидель только какие алерты сейчас «горят» на каких хостах, в PromSQL по запросу ALERTS_FOR_STATE выдает в принципе тоже самое. А хотелось бы посмотреть все проверки, даже если они в состоянии «green». Пока идея в том, что брать переменные из host_vars и другим питон-скриптом генерировать конфиг для alert.rules . Т.е. такая информация (о всех привязанных проверках) будет видна только на уровне ансибла. Может есть какой-то сторонний веб-интерфейс где данная проблема решена?

Ответ на: комментарий от AnDoR

ok, не хост, есть target. Это довольно просто вопрос (про список привязанных проверок), но складывается ощущение, что это никак не реализовано. Вот у нас в одном нагиосе есть 600 проверок, в другом - 3000 проверок - вот как мне иногда контролировать, что мы не «просрали» какие-то проверки (например проверки теперь такой просто нет/для таргета она не применяется)?

unix196 ()
Ответ на: комментарий от unix196

Концепция другая. Вот у тебя есть набор лейблов в метрике. Откуда они взялись - вообще пофигу.
Алерты используют просто эти лейблы, а не какие-то там «хосты» или «таргеты». Какие именно лейблы - зависит от запроса в алерте.

AnDoR ★★★★★ ()
Ответ на: комментарий от AnDoR

хорошо, а в рамках этой концепции с labels возможно организовать то, что упомянуто в начале топика? Пусть, например, будет каждому таргету назначен свой label, возможно ли вывести все алерты, привязанные к этому label?

unix196 ()
Ответ на: комментарий от unix196

У тебя не алерты привязаны к label, а запросы в этих алертах.
Алертов с одинаковым набором лейблов может быть несколько с разными запросами в каждом, например.

Де-факто алерты - это правила аггрегации. Что-то типа materialized view в sql.
Можно ли по materialized view select * from tablename where fieldname ~ "prefix(host1|host2)?suffix" сказать, будет ли оно применяться к записи в таблице с полем fieldname = "prefixhost3suffix"? Вот твой вопрос примерно так же звучит.

AnDoR ★★★★★ ()
Последнее исправление: AnDoR (всего исправлений: 2)