У меня есть среда, в которой я централизованно отслеживаю с помощью Nagios ряд клиентских сред. Идея здесь не в том, чтобы полностью управлять этими средами, а скорее в том, чтобы позволить среде быть в значительной степени автономной и функционировать как путь эскалации для проблем, которые не могут быть решены напрямую.
Я обнаружил, что использование NSCA в качестве метода уведомления имеет некоторые преимущества перед более распространенной распределенной системой мониторинга, использующей навязчиво-компульсивную команду. А именно, я могу использовать логику уведомлений в Nagios, чтобы настроить, какие проблемы будут обостряться и при каких условиях. Например, заказчик может признать проблему до того, как мы вмешаемся, что невозможно в распределенных конфигурациях, основанных на обсессивно-компульсивной основе.
Проблема в том, что при потере уведомления два экземпляра могут потерять синхронизацию. Для отказавших сервисов это легко решить с помощью эскалации сервиса; если уведомление об ошибке не получено, в ближайшее время снова будет отправлено другое. Однако мне кажется, что уведомления о восстановлении никогда не отправляются повторно, независимо от настроек эскалации. Таким образом, если центральное местоположение получает уведомление о сбое, но пропускает уведомление о восстановлении, два местоположения навсегда останутся не синхронизированными.
Это решение было бы идеальным, если бы я мог повторно отправлять уведомления о состоянии ОК через некоторый интервал, даже если не было никаких изменений, но я не вижу способа сделать это. В противном случае, какие еще решения я не рассматривал?
После обстоятельного исследования ответ кажется просто «нет». Уведомления о восстановлении не отправляются повторно ни при каких обстоятельствах.
Альтернативой является использование обсессивно-компульсивная служба / хост-команда вызвать NSCA после каждый чек. Это гораздо более распространенная конфигурация.