У меня есть сервер Rocky Linux 9.2. Мы отслеживаем его через check_mk и регулярно получаем предупреждение о том, что последнее время с момента синхронизации может превышать 1 час. Обратите внимание, что в источниках ниже источник mansfield.id.au находится на 64 минутах.
Исходя из моего ограниченного понимания ntp, maxpoll 10, указанный ниже, равен 1024 секундам?
server 0.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 1.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 2.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 3.au.pool.ntp.org iburst minpoll 6 maxpoll 10
Отслеживание - после того, как chrony наконец синхронизировался, интервал обновления изменился до 4135,0 секунд.
[]#chronyc tracking
Reference ID : 6EE87216 (mansfield.id.au)
Stratum : 3
Ref time (UTC) : Wed Jan 24 00:27:13 2024
System time : 0.000012703 seconds slow of NTP time
Last offset : -0.000079763 seconds
RMS offset : 0.000147473 seconds
Frequency : 10.848 ppm fast
Residual freq : -0.001 ppm
Skew : 0.052 ppm
Root delay : 0.032765601 seconds
Root dispersion : 0.005266702 seconds
Update interval : 1036.2 seconds
Leap status : Normal
Источники
[]# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- 192.9.171.167 2 10 377 254 +511us[ +511us] +/- 63ms
^* mansfield.id.au 2 10 377 64m -2117us[-2197us] +/- 19ms
^- ntp2.ds.network 2 10 377 1007 +16ms[ +16ms] +/- 173ms
^- 220-158-215-20.broadband> 2 10 377 943 +73us[ +73us] +/- 81ms
Кто-нибудь знает, почему он игнорирует значение maxpoll или есть какая-то конфигурация, которая отсутствует/неверна?
Спасибо
джей си
решение1
Это здоровый хронический вывод. Четыре источника, все недавно доступные, точность в диапазоне ниже 1 мс и задержка в десятки миллисекунд, и вы в 3 скачках (страте) от опорных часов. Типично для интернет-серверов NTP.
Ваш вывод там я бы не считал подлежащим действию, и поэтому не является темой для оповещения. Возможно, какая-то временная проблема исчезла после срабатывания оповещения, или проверка неправильно оповещает о вещах.
Конфигурация poll/minpoll/maxpoll chrony — это log base 2, поэтому типичные значения 10 составляют 1024 секунды. Да, это нормально для здоровых экземпляров chrony ослаблять пакеты и в конечном итоге отправлять только несколько в час. Возможен гораздо более длинный maxpoll, но приблизительно никто не меняет значение по умолчанию.
Я не знаком с checkmk. К счастью, у него, похоже, есть ядро с открытым исходным кодом и плагином crony. Я исхожу изchrony.py помечен как v2.2.0. Это ключи, которые он извлекает из chronyc trackingвыходных данных .
Reference ID
System time
Stratum
Ref time (UTC)
Проверка использует текущее время за вычетом проанализированного Ref-времени, чтобы создать порог для "Времени с последней синхронизации" с порогами по умолчанию 1800 и 3600 секунд. Кажется, что приходится анализировать отформатированное время, что может привести к ошибкам, но, по крайней мере, они используют функции библиотеки Python.
Я думаю, что эта часть оповещения бессмысленна и не требует действий. Неудачная синхронизация вернет ошибку stratum number 16, а проверка уже выдает оповещения на stratum > 10. Проверка также выдает оповещения, если не может проанализировать IP-адрес из Reference ID. И даже если chrony потеряет все входные данные, она продолжит дисциплинировать часы на основе известного дрейфа.
Отключите часть задержки этой проверки. Или, по крайней мере, установите ее на гораздо более высокий порог, может быть, 1 или 2 дня. Мне все равно, что последний пакет NTP был 30 минут назад, но 30 часов на постоянно включенном сервере без измерения опорных часов могут быть интересны.
Также диверсифицируйте свои источники, включив неинтернетовские. Если вы имеете дело с оборудованием, вы можете получить устройства NTP, вероятно, из спутникового сигнала. Или в локальной сети уже может быть сервер NTP, в некоторых облаках он есть как часть службы метаданных.