Ad Widget

Collapse

Подавить все триггеры по хосту при условии

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • teddy
    Senior Member
    • Dec 2017
    • 234

    #1

    Подавить все триггеры по хосту при условии

    Хочу реализовать логику:
    Если на хосте алерт (активный триггер) host.down то все другие алерты по этому хосту должны подавляться на время активного триггера host.down.
    В рамках одного шаблона это легко делается зависимостью триггеров. но на хостах разные шаблоны и все их в один никак не объединить.
    Условие можно строить по тегам, но Events colleration не подходит. в корреляции есть только один тип действия - закрыть алерты. и такие алерты в 99% случаев откроются заново, т.к ситуация то не поменялась. Нужно подавить сработку триггеров на время активного триггера host.down
    Возможно это надо делать только через API, но даже если я по тегам через API сделаю подавление, то остается вопрос как вернуть работу триггеров после закрытия алерта host.down. Причем вернуть то надо только те,, что подавлены на предидущем этапе. если что то подавлено вручную - это затронуть не должно.
    Может кто-то нечто подобное реализовывал?

    Есть альтернативный путь без подавления алертов - через API для хостов уже после применения шаблонов указывать зависимость триггеров. Запускать такую штуку переодически для перестройки на случай появления нового хоста или изменения шаблонов. Но как такое сделать через API я не очень понимаю.
  • Alex_UUU
    Senior Member
    • Dec 2018
    • 541

    #2
    Хм, интересно. В данном случае пытались ставить такие сервера на обслуживание. Можно через АПИ.
    Кстати, если на этот триггер прописать свое "действие", то при сработке ты можешь делать скриптом все, что хочешь. Хоть деактивировать все оставшиеся триггеры, хоть поставить на обслуживание, хоть именно в этот момент прописать зависимости.
    ПРи восстановлении - также действием вернуть все в зад.

    Корреляция мне не нравится тем, что она историю портит и статистику активных триггеров.

    Comment

    • teddy
      Senior Member
      • Dec 2017
      • 234

      #3
      проблема не в том как деактивировать все открытое. это более менее понятно. как вернуть назад именно то, что ты поменял?! вот в чем вопрос. ведь если я скриптом по сработке дективирую все активные тригеры, то при возврате я никак не отличу - был такой триггер неактивным по каким то причинам по настройкам или я его деактивировал своим предидущим шагом. была мысль проставлять тег и потом его убирать при деактивации. но как то уж слишком наворочено получается и я не очень понимаю как это все можно сделать скриптом - нет у меня опыта работы с АПИ из скрипта. пока только разбираюсь с этим. Надеялся у кого то есть более элегантное решение.

      и еще вы упомянули "проставить зависимости". а можно ли сделать так - некий скрипт по крону проходится по хостам из группы и прописывает для каждого хоста зависимости всех тригеров от нужного мне "host down" ? если это возможно - то раз в сутки ( а можно и реже -не так часто меняется конфигурация хостов) проставить зависимости - нагрузка не велика даже если скрипт будет работать долго. а остальное сделает сам сервер. очень красиво вроде бы получается, но нужна помощь в написании такого скрипта.​

      Comment

      • Alex_UUU
        Senior Member
        • Dec 2018
        • 541

        #4
        Через апи можно мноое.
        Насчет крона. Считаю, что в ег качестве можно использовать ЭД заббикса. Это будет намного прозрачнее.
        С тегами - хорошая идея. Через АПИ можно апдейтить и получать.
        Если запросы к АПИ непонятны - есть фича: в настройках доступа для группы ставишь галочку "отладка". И на каждой странице внизу появляется кнопочка.
        Жамкешь - открывается дебаг со всеми запросами в АПИ и, кажется, в БД.

        Comment

        Working...