Chrony 同步時間忽略 maxpoll

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

這是健康的慢性輸出。四個來源,最近均可到達,精度在 1 毫秒以下,延遲在數十毫秒內,並且距離參考時鐘有 3 跳(層)。典型的網際網路 NTP 伺服器。

我認為你的輸出不具可操作性,因此不值得警惕。警報觸發後,某些臨時問題可能不再存在,或檢查錯誤地發出警報。

chrony 的 poll/minpoll/maxpoll 配置是以 log 2 為底的,因此 10 的典型值為 1024 秒。是的,健康的慢性實例減少資料包並最終每小時僅發送幾個資料包是正常的。 maxpoll 可能會更長,但幾乎沒有人更改預設值。

我對 checkmk 不熟悉。幸運的是,它似乎有一個帶有 crony 插件的開源核心。我要離開chrony.py 標記為 v2.2.0。這些是它從chronyc tracking輸出中提取的鍵

Reference ID
System time
Stratum
Ref time (UTC)

檢查使用當前時間減去解析的參考時間來設定「自上次同步以來的時間」的閾值,預設閾值分別為 1800 和 3600 秒。似乎很容易出錯,必須解析格式化的時間,但至少他們使用了Python庫函數。

我認為警報的這一部分毫無意義且不可操作。同步失敗將傳回錯誤層數 16,並且檢查已在層 > 10 上發出警報。即使 chrony 丟失所有輸入,它也會根據已知的漂移繼續規範時鐘。

停用此檢查的延遲部分。或至少將其設定為更高的閾值,也許 1 或 2 天。我不在乎最後一個 NTP 封包是在 30 分鐘前,但在沒有參考時鐘測量的始終在線伺服器上的 30 小時可能會很有趣。

也要讓您的來源多樣化,包括非網路來源。如果您處理硬件,您可以獲得 NTP 設備,可能來自衛星訊號。或者在本地網路上可能已經有一個 NTP 伺服器,在某些雲端中,有一個作為元資料服務的一部分。

相關內容