У меня есть локальный NTP-сервер, работающий в подсети, чтобы синхронизировать другие узлы подсети, без синхронизации каждого узла с вышестоящими серверами. Но при реализации check_ntp_time плагин для Nagios. Я заметил неприятную проблему, когда nagios продолжает сообщать о критических ошибках для локальных узлов, синхронизирующихся с локальным ntp-сервером.
Вот конфигурация ntp на локальном сервере ntp, обратите внимание на восходящий поток сервер записи и ограничивать запись, согласно моим исследованиям, это квалифицирует узел как ntp-сервер, с которым могут синхронизироваться локальные узлы.
driftfile /var/lib/ntp/drift
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1
# Makes me able to answer requests from local nodes
restrict 10.0.0.0 mask 255.255.192.0 nomodify notrap
# My source
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
logfile /var/log/ntp/server.log
statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable
А на локальных узлах не-ntp-серверов все то же самое, кроме ограничивать запись удаляется, а сервер записи ссылаются только на локальный сервер ntp: server ntp.example.com iburst.
Каждый локальный узел может разрешить ntp.example.com.
Проблема, с которой я столкнулся, заключается в том, что я запускаю следующую команду с сервера nagios:
/usr/lib64/nagios/plugins/check_ntp_time -H node-a-1 -v
И вывод:
sending request to peer 0
response from peer 0: offset -0.002921819687
sending request to peer 0
response from peer 0: offset -0.0001939535141
sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
discarding peer 0: stratum=0
overall average offset: 0
NTP CRITICAL: Offset unknown|
Это происходит для всех узлов, кроме локального ntp-сервера, который ссылается на вышестоящие серверы. Сначала я подумал, что это проблема IPTables, но у меня есть порты на каждом локальном узле ntp (чтобы разрешить доступ nagios для проверки разницы во времени):
ACCEPT udp -- eth0 * 10.0.0.0/18 0.0.0.0/0 multiport dports 123 /* 777 allow ntp access */ state NEW
Версии:
nagios-plugins-ntp: 1.4.16
ntp: 4.2.6p5-1.el6.centos
Любая помощь приветствуется, я действительно не могу отправить работу nagios, пока не решу эту проблему, так как вы знаете, что синхронизация времени сервера является приоритетом 1.
-- Редактировать --
Согласно комментариям, вот результаты ntpq -p, на различных узлах:
# Actual NTP Server (10.0.0.2)
==============================================================================
+propjet.latt.ne 241.199.164.101 2 u 105 128 337 14.578 12.954 7.138
+x2la01.hostigat 63.145.169.2 3 u 21 128 377 16.037 13.546 4.090
*pacific.latt.ne 241.199.164.101 2 u 72 128 377 15.148 24.434 7.403
# Local node 1
==============================================================================
*service-a-1.sn1 204.2.134.163 3 u 9 128 377 0.228 5.217 1.296
# Local node 2
==============================================================================
*service-a-1.sn1 204.2.134.163 3 u 91 128 377 0.200 3.608 1.167
Ключевая линия здесь такая:
отклонение однорангового узла 0: stratum = 0
Сервер NTP, идентифицирующий себя как слой 0, является нарушением спецификации (он зарезервирован для атомных часов или чего-то подобного). У меня была эта проблема много лет назад с некоторыми хостами BSD и Mac OS X. Я закончил тем, что взломал проверку страты из источника и поддерживал отдельную сборку плагина для «проблемных» хостов.
Оскорбительные строки: 254-257. (в настоящее время, по крайней мере), если вы хотите вырвать это. Это хак, но у меня он работает ;-)
я нашел эта тема в архивах списка рассылки об этом. Я думаю, что был еще один, где я предлагал добавить параметр командной строки, чтобы игнорировать проверку страты, но я не думаю, что он получил какую-либо поддержку.
Также есть отчет об ошибке об этом, но, насколько я могу судить, это не дало ничего полезного.
Я устранил проблему, отключив функцию KOD (поцелуй смерти) на сервере NTP.
check_ntp отправляет (как минимум) 4 запроса в быстрой последовательности для расчета статистически надежного среднего смещения. Третий и все последующие запросы рассматриваются сервером как отказ в обслуживании, и на них отправляется сообщение KOD (недопустимый уровень, а именно 0). Фактически, такое поведение следует рассматривать как ошибку check_ntp, поскольку KOD должен правильно обрабатываться клиентом.