☰

Chrony 同步时间忽略 maxpoll

tag-icon • tag-icon time-synchronization chrony
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 值，或者是否存在某些缺失/错误的配置？

谢谢

杰

答案1

这是健康的 chrony 输出。四个源，最近都可以访问，精度在 1 毫秒以下，延迟在几十毫秒内，并且您距离参考时钟有 3 个跳数（层）。这对于互联网 NTP 服务器来说很常见。

我认为您的输出不可行，因此不值得警告。可能某些临时问题在警报触发后不再存在，或者检查错误地警告了某些事物。

chrony 的 poll/minpoll/maxpoll 配置是以 2 为底的对数，因此 10 的典型值是 1024 秒。是的，健康的 chrony 实例会减少数据包数量，最终每小时只发送几个数据包，这是很正常的。更长的 maxpoll 是可能的，但几乎没有人会更改默认值。

我不熟悉 checkmk。幸运的是，它似乎有一个带有 crony 插件的开源核心。我要去chrony.py 标记 v2.2.0chronyc tracking。这些是从输出中提取的键

Reference ID
System time
Stratum
Ref time (UTC)

检查使用当前时间减去解析的 Ref 时间来设定“自上次同步以来的时间”的阈值，默认阈值显然为 1800 秒和 3600 秒。解析格式化的时间似乎容易出错，但至少它们使用了 Python 库函数。

我认为警报的这一部分毫无意义且不可操作。同步失败将返回错误层号 16，而检查已在层 > 10 上发出警报。如果无法从参考 ID 解析 IP 地址，检查也会发出警报。即使 chrony 丢失了所有输入，它仍会根据已知的偏差继续校准时钟。

禁用此检查的延迟部分。或者至少将其设置为更高的阈值，可能是 1 或 2 天。我不关心最后一个 NTP 数据包是在 30 分钟前，但在没有参考时钟测量的情况下始终在线的服务器上运行 30 小时可能会很有趣。

还要多样化您的来源，包括非互联网来源。如果您处理硬件，您可以获得 NTP 设备，可能是通过卫星信号。或者本地网络上可能已经有一个 NTP 服务器，在某些云中，有一个 NTP 服务器作为元数据服务的一部分。

相关内容