Я пытаюсь найти решение для описанного ниже сценария.
У меня есть несколько сотен служб в Nagios (установка OMD с check_mk и другими вкусными вещами), и они определены как разные типы служб, поэтому для разных типов у меня есть разные группы контактов, которые будут предупреждены при возникновении проблемы.
Он работает хорошо, но я хотел бы вызвать сценарий, если служба находится в критическом состоянии через 1 час и не была подтверждена / прокомментирована и т. Д.
В справочной документации ничего не нашел.
Заранее спасибо за вашу помощь
Типичный вид услуги:
define contact{
contact_name level1 ; Short name of user
use generic-contact ; Inherit default values from
alias Gravity Level1 ; Full name of user
email wtf@spamcop.net ; email for alerting
}
define contactgroup{
contactgroup_name defcon3
members level1, level2
}
define service{
name defcon3-service ; The 'name' of this service template
active_checks_enabled 0 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service 'freshness'
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across
is_volatile 0 ; The service is not volatile
check_period 24x7 ; The service can be checked at any time of the day
max_check_attempts 3 ; Re-check the service up to 3 times in order to
normal_check_interval 2 ; Check the service every 10 minutes under normal
retry_check_interval 1 ; Re-check the service every two minutes until a
notification_options w,u,c,r ; Send notifications about warning, unknown,
notification_interval 60 ; Re-notify about service problems every hour
notification_period 24x7 ; Notifications can be sent out at any time
contact_groups defcon3 ; default mail to monitoring -v-
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A R
}
define service {
use check_mk_passive_perf
use defcon3-service
host_name gravity-mon
service_description CPU load
contact_groups +defcon3
service_groups +defcon3
check_command check_mk-cpu.loads
}
Я ненавижу прямо противоречить другому плакату, но NAGIOS может сделать именно это: то, что вы ищете, в документации упоминается как эскалация уведомлений.
Как говорит доко,
Уведомления повышаются тогда и только тогда, когда одно или несколько определений эскалации соответствуют текущему отправляемому уведомлению. Если уведомление узла или службы не имеет действительных определений эскалации, которые применяются к нему, для уведомления будет использоваться контактная группа (группы), указанная в определении группы узлов или службы.
Итак, если у вас была служба под названием HTTP на хосте webserver, отказ которого обычно предупреждал группу sysadmins каждые 30 минут (скажем), и вы хотели, чтобы группа managers чтобы услышать об этом, если несколько раз предупреждения были неподтвержденными и не были исправлены третьим предупреждением, вы можете попробовать:
define serviceescalation{
host_name webserver
service_description HTTP
first_notification 3
last_notification 5
contact_groups nt-admins,managers
}
В вашем случае вы хотите не уведомлять людей, а вызывать скрипт. Для этого вам необходимо определить новую контактную группу, содержащую одного члена, у которого есть service_notification_commmand из (например) /usr/local/bin/my-webserver-handling-script.
Если вы не хотите, чтобы скрипт запускался повторно, вам нужно настроить first_notification и last_notification выше, так что эта конкретная эскалация применяется только один раз.
Я бы также предупредил вас об этом. Я лично не поддерживаю превращение систем уведомления в системы обработки инцидентов; Я думаю, они должны дать человеку понять, что что-то не работает, и позволить человеку разобраться с этим, и вот почему: по определению NAGIOS предупреждает людей только тогда, когда что-то не идет нормально. Если вы собираетесь автоматизировать работу с этим, вам нужно чрезвычайно уверен, что они потерпели неудачу именно в правильном направлении. Если, например, вы собираетесь использовать этот скрипт для включения и выключения веб-сервера, тогда вам лучше быть абсолютно уверенным, что все зависимости вашего хоста настроены правильно, чтобы отказ промежуточного маршрутизатора также не стал причиной вашего веб-сервер, чтобы начать жесткую перезагрузку, что приведет к повреждению файловой системы, с которым вам придется иметь дело после исправления маршрутизатора.