У нас есть массив серверов, любой из которых может выйти из строя, генерируя уведомление со средним приоритетом:
define host {
host_name foo1
contacts medium-priority
use default-host
}
...
Однако мы хотели бы получать уведомление с более высоким приоритетом, когда более, чем два у таких серверов проблемы. С этой целью мы создали отдельное определение службы, используя Nagios / Icinga check_cluster-утилита:
define service {
service_description foo-cluster
servicegroups cluster-checks
display_name Foo Cluster
check_command check_cluster_host!Foo Cluster!0!3!$HOSTSTATEID:foo1$,$HOSTSTATEID:foo2,...$HOSTSTATEID:fooN$
contacts high-priority
hostgroup_name clusters
notes Check, that no more than 2 hosts in group foo are in trouble
use default-service
}
Вышеупомянутое, вероятно, сработает, но я бы хотел, чтобы эта служебная проверка запускалась не по времени, а только по изменение статуса любого из "нижележащих" хостов ...
Мы генерируем конфигурационные файлы Icinga с помощью Ansible и поэтому можем программно конструировать сложные зависимости, но можно ли реализовать такой запуск вообще?
Вы можете определить обработчик событий на хосте, который в основном представляет собой небольшой скрипт, «делающий что-то на основе параметров». Атрибуты состояния хоста можно передать из макросов времени выполнения в качестве параметров команды.
https://www.icinga.com/docs/icinga1/latest/en/eventhandlers.html
Я бы пошел по маршруту и определил настраиваемую переменную на хосте, которая определяет службы, запускаемые при запуске обработчика событий. Таким образом, вам не нужно жестко закодировать их внутри скрипта.
Затем ваш сценарий может решить принудительно выполнить новую проверку службы через внешний командный канал. Вероятно, вам следует определить, достаточно ли состояний HARD или SOFT - имейте в виду, что обработчики событий запускаются только при изменении состояния, а не, например, при DOWN-> DOWN-> DOWN.
Пример: https://github.com/Icinga/icinga-core/blob/master/contrib/eventhandlers/submit_check_result.in
Примечание. В этой службе не должны быть включены активные проверки и использоваться не фиктивная команда, а фактическая команда проверки службы.
(такая отправка результатов проверки происходила в старом мире Nagios / Icinga1 для несколько хакерского распределенного мониторинга, если вы ищете больше примеров с командным конвейером и обработчиками событий).