возможно ли в nagios проверить хост перед уведомлением службы

Что-то должно быть неправильно сконфигурировано, или хост подключается быстрее, чем проверка службы дает сбой. Даже в URL-адресе, опубликованном Халедом, говорится, что проверки хоста выполняются по запросу, когда служба меняет состояние:

Хосты проверяются демоном Nagios:

• Через регулярные промежутки времени, как определено параметрами check_interval и retry_interval в определениях вашего хоста.
• По запросу, когда служба, связанная с хостом, меняет состояние.
• По запросу по мере необходимости как часть логики доступности хоста.
• По запросу, если это необходимо для прогнозных проверок зависимостей хоста.

Это в основном говорит о том, что Nagios будет проверять через заданные интервалы и при изменении состояния службы. Когда служба выходит из строя (переходит в состояние ПРЕДУПРЕЖДЕНИЕ / КРИТИЧЕСКОЕ), выполняется проверка хоста, и если хост рассматривается как неработающий, он должен подавить уведомления службы, если вы настроили его таким образом. Можете ли вы показать нам свои сервисы и определения хостов, замаскируя любое имя хоста / адреса, чтобы защитить невиновных, если хотите.

В качестве примечания, я использую Nagios в течение многих лет и никогда не получал оповещений службы, когда хост находится в нерабочем состоянии, если я специально не настроил его для этого.

Старый пост, но, вероятно, стоит упомянуть достаточно распространенный случай с хостами, которые постоянно настроены на отклонение пингов и т. Д., Но нуждаются в мониторинге некоторых видимых служб.

В этих случаях, как указано здесь: Хостинг Nagios отключен, но услуги включеныможно использовать фиктивную проверку, чтобы игнорировать хост и вместо этого использовать службы.

То, что я обычно делаю (nagios 3.x), чтобы получить значимую проверку хоста в этих случаях, - это изменить команду проверки хоста, чтобы использовать check_tcp на порту, который, как я знаю, есть отслеживаемая служба, обычно порт 80, и изменить check- host-alive, чтобы вызвать это через соответствующий порт:

# Alternative to 'check-host-alive' command for hosts that can't be pinged
define command {
        command_name    check-host-alive-alt
        command_line    $USER1$/check_tcp -H $HOSTADDRESS$ -p $ARG1$
}

и настройте хост с

define host {
    use             some-server-template
    name            an-unpingable-webserver

    # <other host config directives>

    check_command   check-host-alive-alt!80
}

и полагаться на зависимости служб, чтобы решить, следует ли проверять другие службы, и установить связь с вашей системой тикетов (с помощью специальной команды уведомления службы). По крайней мере, вы знаете, что если проверка хоста не работает, что-то не так.

Я не думаю, что это возможно. Nagios регулярно составляет расписание проверок служб и хостов. Кроме того, он проверяет статус хоста при изменении статуса службы. Вы можете посмотреть на эта страница.

Думаю, вам нужно реализовать этот механизм самостоятельно, если он вам нужен. Например, вы можете получить и сохранить изменение статуса услуги. Затем вы можете отправить уведомление только в том случае, если статус хоста не изменится (в результате другой проверки или по истечении некоторого времени ожидания).

Это должно быть возможно с зависимостями
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/dependencies.html
Вот отрывок с сайта:

Как тестируются зависимости сервисов

Прежде чем Nagios выполнит проверку службы или отправит уведомления для службы, он проверит, есть ли у службы какие-либо зависимости. Если у него нет никаких зависимостей, выполняется проверка или отправляется уведомление, как обычно. Если у службы есть одна или несколько зависимостей, Nagios будет проверять каждую запись зависимости следующим образом:

• Nagios получает текущий статус * службы, от которой зависит.
  
• Nagios сравнивает текущий статус службы, от которой зависит выполнение, или сбой уведомления.
  параметры в определении зависимости (в зависимости от того, что актуально в
  время).
  
• Если текущий статус службы, от которой зависит, совпадает с одним из вариантов отказа, говорят, что зависимость имеет
  не удалось, и Nagios выйдет из цикла проверки зависимостей.
  
• Если текущее состояние службы, от которой зависит, не соответствует ни одному из вариантов отказа для записи зависимости,
  считается, что зависимость пройдена, и Nagios продолжит проверку следующей записи зависимости.