Check_MK NTP UNKNOWN - нет информации от NTP: тайм-аут в ntpq -p или демон NTP не запущен

Был бы очень признателен за помощь с этим.

У меня есть удаленный сервер, который постоянно сообщает мне «НЕИЗВЕСТНО - нет информации от NTP: тайм-аут в ntpq -p или демон NTP не запущен» через наш мониторинг Check_MK.

По сравнению с другими серверами все в порядке. Поддержка Aksing Check_MK, и они говорят мне, что это проблема ntp сервера, а не проблема мониторинга.

Я знаю ... сегодня пятница! Обычно это происходит часто ночью и несколько раз в течение дня.

мой /etc/ntp.conf это ....:

server 213.239.239.164 iburst
server 213.239.239.165 iburst
server 213.239.239.166 iburst

Любые идеи были бы хорошы..

Ubuntu 14.04 Физический сервер

Спасибо

Боб

Эта ошибка фактически прекратилась, когда я установил обновление Check_MK agent 1.4 поверх версии 1.2. Я сделал это вчера и с тех пор не получил никаких сообщений ntp unknown от Check_MK для этого сервера.

Большое спасибо за очень подробный ответ.

боб

Я только что установил виртуальную машину Ubuntu 14.04 с той конфигурацией, которую вы показали:

root@localhost:~# apt-cache policy ntp
ntp:
  Installed: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11
  Candidate: 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11
  Version table:
 *** 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11 0
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1:4.2.6.p5+dfsg-3ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
root@localhost:~# cat /etc/ntp.conf
server 213.239.239.164 iburst
server 213.239.239.165 iburst
server 213.239.239.166 iburst
root@localhost:~# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*213.239.239.164 192.53.103.103   2 u   26   64    1   15.098   -0.522   0.050
 213.239.239.165 192.53.103.103   2 u   25   64    1   19.043    0.288   0.247
 213.239.239.166 192.53.103.108   2 u   24   64    1   18.900   -1.900   0.206

Это работает правильно; он разрешает ntpq локально и игнорирует его удаленно из-за ограничений по умолчанию. Итак, мои догадки о причине вашей конкретной проблемы:

старая конфигурация, реализующая нестандартные ограничения
локальный брандмауэр в рассматриваемой системе или на вашем хосте мониторинга check-mk, возможно, включающий полную таблицу отслеживания соединений
вы изменили ограничения apparmor ntpd по умолчанию таким образом, чтобы это повлияло на его сетевое подключение
высокая нагрузка на хост check-mk, целевой хост или сеть между ними, что приводит к потере пакетов где-то по пути

Кроме того, использование таких необработанных IP-адресов - отличный способ в конечном итоге получить неработающий NTP, когда hetzner решит изменить IP-адреса своих серверов NTP. С помощью pool ntp.hetzner.de iburst дает тот же результат и является предпочтительной конфигурацией.