Chrony синхронизирует время, игнорируя maxpoll.

У меня есть сервер 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, или есть какие-то конфигурации, которые отсутствуют/неправильные?

спасибо

jc

Это нормальный вывод chrony. Четыре источника, все доступны недавно, точность ниже 1 мс и задержка в десятки миллисекунд, и вы находитесь в 3 прыжках (уровень) от опорных часов. Типично для интернет NTP серверов.

Ваш вывод я бы не считал актуальным, и поэтому не стал бы на него реагировать. Возможно, какая-то временная проблема больше не существует после того, как сработало предупреждение, или проверка неправильно реагирует на что-то.

Конфигурация chrony’s poll/minpoll/maxpoll — логарифм по основанию 2, поэтому типичные значения 10 — это 1024 секунды. Да, для здоровых экземпляров chrony нормально уменьшать количество пакетов и в итоге отправлять только несколько в час. Возможен более длительный maxpoll, но почти никто не меняет значение по умолчанию.

Я не знаком с checkmk. К счастью, у него есть открытая исходная часть с плагином crony. Я ссылаюсь на chrony.py tagged v2.2.0. Вот ключи, которые он извлекает из вывода chronyc tracking

Reference ID
System time
Stratum
Ref time (UTC)

Проверка использует текущее время за вычетом разобранного времени Ref, чтобы создать порог для “Время с последней синхронизации” с видимо установленными по умолчанию порогами 1800 и 3600 секунд. Кажется ошибочным парсить отформатированное время, но как минимум они используют функции библиотеки Python.

Я считаю эту часть предупреждения бессмысленной и бездействующей. Невозможность синхронизации вернет ошибку с номером уровня 16, и проверка уже оповещает о stratum > 10. Проверка также предупреждает, если не удается распарсить IP-адрес из Reference ID. И даже если chrony утратит все входные данные, он продолжит дисциплинировать часы на основе известного отклонения.

Отключите часть проверки, связанную с задержкой. Или, по крайней мере, установите для нее более высокий порог, возможно, 1 или 2 дня. Меня не волнует, если последний пакет NTP был отправлен 30 минут назад, но 30 часов на сервере, который всегда включен, без измерения контрольных часов может быть интересно.

Так же разнообразьте свои источники, включив не интернетные. Если вы работаете с оборудованием, вы можете получить NTP устройства, вероятно, работающие от спутникового сигнала. Или на локальной сети уже может быть NTP сервер, в некоторых облаках он есть как часть метаданных сервиса.

После обновления до версии 2.0.0p39, я наблюдаю ту же проблему. Давайте убедимся, что мы сосредоточены на фактах, предоставленных jc.

Для сервера mansfield.id.au:

• Опрошено 10. Это 1024 секунды. Это чуть больше 17 минут.
• Доступность 377. Это означает, что все последние 8 опросов были успешны.
• Тем не менее, LastRx составляет 64 минуты. Как это может быть больше чем 1024 секунды?

Это не проблема Checkmk. Либо я не понимаю вывод “chronyc sources”, либо это баг.

— Джей