私は 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
答え1
これは正常な chrony 出力です。4 つのソースはすべて最近アクセス可能で、精度は 1 ミリ秒未満、遅延は数十ミリ秒で、基準クロックからは 3 ホップ (階層) 離れています。インターネット NTP サーバーでは一般的です。
ここでの出力は、対処可能なものではないため、警告の対象にはなりません。警告が発せられた後に一時的な問題がなくなったか、チェックが誤って警告を発している可能性があります。
chrony の poll/minpoll/maxpoll 設定は 2 を底とする対数なので、10 の典型的な値は 1024 秒です。はい、正常な chrony インスタンスがパケットを緩和し、1 時間に数個しか送信しなくなるのは正常です。maxpoll をもっと長くすることも可能ですが、デフォルトを変更する人はほとんどいません。
checkmkについてはよく知りません。幸い、cronyプラグインを備えたオープンソースのコアがあるようです。chrony.py タグ付き v2.2.0chronyc trackingこれらは出力から抽出されるキーです
Reference ID
System time
Stratum
Ref time (UTC)
Check は、現在の時刻から解析された Ref 時刻を引いた値を使用して、「最後の同期からの時間」のしきい値を作成します。デフォルトのしきい値は 1800 秒と 3600 秒のようです。フォーマットされた時間を解析する必要があるためエラーが発生しやすいようですが、少なくとも Python ライブラリ関数を使用しています。
アラートのこの部分は無意味であり、対処できないと思います。同期に失敗すると、エラー ストラタム番号 16 が返され、チェックはストラタム > 10 ですでにアラートを発しています。チェックは、参照 ID から IP アドレスを解析できない場合にもアラートを発します。また、chrony がすべての入力を失った場合でも、既知のドリフトに基づいてクロックを制御を続けます。
このチェックの遅延部分を無効にします。または、少なくともしきい値を 1 日か 2 日など、はるかに高く設定します。最後の NTP パケットが 30 分前だったかどうかは気にしませんが、参照クロック測定のない常時稼働サーバーで 30 時間というのは興味深いかもしれません。
また、インターネット以外のソースも含め、ソースを多様化します。ハードウェアを扱う場合は、衛星信号から NTP アプライアンスを入手できます。または、ローカル ネットワークにすでに NTP サーバーがある場合もあります。一部のクラウドでは、メタデータ サービスの一部として NTP サーバーが存在します。