У меня есть то, что я считаю обычной настройкой Nagios: когда у хоста или службы возникает проблема, он отправляет электронное письмо дежурному человеку, а затем продолжает отправлять электронные письма каждый час, пока проблема не будет подтверждена или не исчезнет сама по себе.
Теперь я хотел бы передать проблемы (и решения и т. Д.) В систему регистрации, и я не хочу видеть ежечасные сообщения «служба все еще не работает». Я просто хочу увидеть сначала «Служба сломана», затем (возможно) «Проблема подтверждена», а затем, в конце концов, «Служба в порядке». (В частности, я вхожу в канал Slack, но не думаю, что эти детали повлияют на решение.)
Есть ли простой способ настроить контакт «журнала», который будет получать уведомление о первом сбое службы или хоста, но не о повторяющихся?
Один из теоретически возможных способов сделать это - эскалация. Вот пример служебных уведомлений:
define serviceescalation {
host_name *
service_description *
contacts slack
first_notification 1
last_notification 1
escalation_options w,c,u
}
define serviceescalation {
host_name *
service_description *
contacts slack
first_notification 1
last_notification 0
escalation_options r
}
К сожалению, он получает только предупреждения, критические, неизвестные и уведомления о восстановлении. Я также хотел бы регистрировать уведомления о сбоях и простоях, которые, похоже, вообще не проходят через систему эскалации.
Вы можете включить ведение журнала syslog в основном файле конфигурации, а затем использовать такой инструмент, как syslack, бревно в резервили аналогичный для отправки в Slack.
Кроме того, как вы подозревали / намекали, вы можете сделать это с помощью эскалации хоста / сервиса, применяемой к группам хостов, сервисным группам и / или используя подстановочные знаки.
В Страница документации по хитростям экономии времени показывает некоторые способы широкого применения эскалации.
Вы также можете написать собственный сценарий уведомления (часто решение для сложных требований к уведомлениям) или использовать обработчик события (если вам нужно еще больше гибкости).
Если я правильно понял вопрос, вы можете взглянуть на определения объектов хостов и сервисов:
Вы можете установить notification_interval значение 0, Nagios вызовет x_notification_commands когда Сервис или Хост выходят из состояния HARD.
Пример шаблона:
define host{
notification_interval 0
...
_log_level 1
register 0
}
Вы даже можете поиграть с пользовательскими переменными, чтобы установить здесь свои собственные уровни ведения журнала.
Почему вы не можете просто написать собственный сценарий команды уведомлений для контакта? Затем вы можете анализировать потоки сообщений с помощью макросов в любом случае.
define contact{
name log-contact
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands logger-notify-service
host_notification_commands logger-notify-host
register 0
}