Распределите Nagios для сокращения ложных аварийных сигналов
Вы могли использовать offlineimap для получения писем из учетной записи Gmail.
Также выполняя Ваш собственный сервер IMAP и выбирая почту с fetchmail или getmail или обычно синхронизируйте данные со своей учетной записью Gmail (например, использующий imapsync) жизнеспособные варианты. Конечно, необходимо ли думать о синхронизации изменений назад в Gmail, например, что произойдет, если Вы удалите почту в своем локальном сервере IMAP.
Увеличить порог для предупреждения. Например, не будет сигнала тревоги после 1 отказа. Включите сигнал тревоги после 3 сбоев и установите разумный интервал (1 минута, 2 минуты) между повторными проверками. Это означает, что вы будете уведомлены, если он не работает в течение 4-5 минут, а не если у вас есть «временные проблемы с сетью» на вашем сервере мониторинга.
Сначала вы должны отследить причину, по которой истекает время ожидания HTTP-запроса.
Если у вас более 50 серверов и более 5 отслеживаемых значений на каждый сервер, вероятно, что Виновником является сам Nagios.
Он генерирует запрос для каждого события мониторинга и генерирует множество сетевых прерываний.
Вместо повышения порога предупреждения вы можете изменить значения тайм-аута и повтора в http-check-method.
Увеличьте пороговые значения для предупреждения. На самом деле, вам может быть лучше выполнять этот вид мониторинга с помощью сценария, который регистрирует время транзакций, отправляет уведомления в Nagios и периодически анализирует свой журнал последних циклов обработки, чтобы отправлять предупреждение только в случае развития плохой тенденции.
Это позволяет вам установить более высокий порог, чтобы он не предупреждал КАЖДУЮ транзакцию, которая занимает слишком много времени, но все же предупреждал вас, если время транзакции скользящего среднего становится слишком большим. Вы будете немного медленнее реагировать на серьезную проблему, но вы не будете утомлены таким количеством ложных тревог.
В любом случае, реальные серьезные проблемы, возникшие по вашей вине (а не стихийные бедствия или действия оператора центра обработки данных), лучше решать с помощью автоматических перезапусков и перезагрузок, потому что это самый быстрый способ исправить такие проблемы, если они легко устранимы. И если их нелегко исправить, задержка в пару минут, вызванная более высоким порогом, не повлияет на то, как вы восстановитесь после проблемы.
Не бойтесь экспериментировать с порогами. Когда вы готовы реагировать на сигналы тревоги, поэкспериментируйте с более низкими порогами и посмотрите, что произойдет. Увеличьте пороговые значения, когда у вас нет свидания, а потом сделайте обзор, чтобы узнать, не было ли упущено что-нибудь важное.