Что такое липкий комментарий check_mk при подтверждении хоста / сервиса?

Я хотел прикрепить комментарий к системе, которая отслеживается с помощью Nagios. Я предпочитаю использовать check_mk в качестве графического интерфейса. Теперь я наткнулся на это: я могу сделать комментарий липким и / или постоянным.

Поэтому я спросил нашего администратора Nagios, в чем разница между липким и постоянным.

Оказалось, что он не знал о "липком" - это должно быть что-то специфичное для check_mk.

После гугла и просмотра документов check_mk я не смог ничего найти по этой теме.

Итак: В чем разница между закреплением и постоянством для комментариев Nagios-service?

Обновление: вот скриншот - быстрый поиск check_mk для конкретного сервера, затем выберите символ hamer. Тогда это будет отображаться:

Скриншот

Вопрос о коробке подтверждения: липкий против постоянного

3 ответа

Решение

Я отвечу с некоторыми мелкими деталями. Дженни Ди, кстати, но я бы хотел быть более точным в отношении "никаких дальнейших тревог".

Как правило, Nagios будет уведомлять вас о каждом изменении статуса:

  1. Таким образом, если ваш сервис становится "ПРЕДУПРЕЖДЕНИЕ", вы получите уведомление.
  2. Вы подтверждаете услугу сейчас и не будете получать другое (то есть perioditc) уведомление, пока сервис находится в состоянии "WARN".
  3. Если он переходит к "CRIT", вы получаете уведомление.
  4. Если он возвращается к "WARN", вы получите уведомление.
  5. Если затем он идет в "ОК", вы получите уведомление о восстановлении.
  6. После этого срок действия подтверждения истекает, так как он становится "ОК"

В случае залипания будут отсутствовать уведомления о прохождении между проблемными состояниями:

  1. Таким образом, если ваш сервис становится "ПРЕДУПРЕЖДЕНИЕ", вы получите уведомление.
  2. Теперь вы подтверждаете услугу с установленным параметром закрепления.
  3. Если он переходит к "CRIT", вы не получаете уведомления.
  4. Если он возвращается к "WARN", вы не получите уведомление.
  5. Если затем он идет в "ОК", вы получите уведомление о восстановлении.
  6. После этого липкий параметр удаляется, так как это свойство подтверждения - истек, так как он становится "ОК"

В человеческом смысле:

Отключение параметра закрепления означает: я работаю над проблемой, но это займет некоторое время, например, хотя это просто ПРЕДУПРЕЖДЕНИЕ. Я не авторизован для сопоставления нового диска. Если вдруг что-то обострится и файловая система заполнится до CRIT, я должен знать, что с тех пор мы переходим от профилактического обслуживания к аварийному исправлению.

Липкая опция позволяет вам выбрать другой способ сделать это. Я работаю над проблемой и буду следить за ней, пока я работаю. Во время моей работы это может ухудшиться временно, пока я не СДЕЛАН, и тогда это будет хорошо

К вашему сведению: если вы используете опцию постоянного комментария, подтверждение пропадет, но введенный вами текст останется

Вопрос о коробке подтверждения: липкий против постоянного

ОК, это то, что я описал в комментарии выше. Взгляните на это для более подробной информации:

  • Если для параметра "sticky" установлено значение "один" (1), подтверждение останется до тех пор, пока хост не вернется в состояние UP. В противном случае подтверждение будет автоматически удалено при изменении состояния хоста.

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

"Липкий" здесь означает "липкое подтверждение" = дальнейших аварийных сигналов не будет, пока эта проблема не будет решена. Другими словами, тот факт, что вы признали это, будет придерживаться ошибки, даже если та же самая ошибка продолжает генерировать сигналы тревоги. (Конечно, это продолжается до тех пор, пока текущая проблема не будет решена, и проблема не прекратит генерировать аварийные сигналы - в следующий раз, когда произойдет сбой, она снова будет генерировать аварийные сигналы.)

Другие вопросы по тегам