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 Физический сервер

Спасибо

боб

Источник

2 ответа

Решение

Эта ошибка фактически прекратилась, когда я установил обновление Check_MK agent 1.4 поверх версии 1.2. Это я сделал вчера, и с тех пор не получил ntp неизвестных сообщений от 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, возможно, с использованием полной таблицы отслеживания соединений
  • Вы изменили ограничения ntpd apparmor по умолчанию таким образом, что это влияет на его сетевое подключение
  • высокая нагрузка на хост check-mk, целевой хост или промежуточную сеть, что приводит к потере пакетов в пути

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

Источник
Другие вопросы по тегам