内部NTPサーバーが正しい時刻を送信していることを確認しますか？
私は2つのNTP stratum 3サーバーを実行していて、どちらかのサーバーが時間ドリフトしているかどうかを確認し、それがpublic stratum 2サーバーと適切に同期していないことを警告できる簡単なチェックを作成したいと考えていました。
私の最初の考えは、複数のstratum 2サーバーから時間を引き出し、その時間を私のntpサーバーが送信しているものと比較することでした。次に、ドリフトがXデルタを超えているかどうかを警告します。
NTPサーバーが正しい時刻を送信していることを確認するためのより標準的な方法またはより良い方法はありますか？
TL; DR：
- ベストプラクティス に従ってNTPサーバーを設定します。
- （恥知らずな自己宣伝の警告。）my ntpmon を使用して、監視ソリューションがcollectd、Nagios、またはtelegrafを使用しているかどうかを確認します。
ロングバージョン：
構成
適切なNTPモニタリングの最も重要な基盤は、適切なNTP構成です。これを最もよく理解するには、 NTP Best Current Practices（BCP 223/RFC 8633） をお読みください。構成の推奨事項の要約は次のとおりです。
- NTPソフトウェアを最新の状態に保つ
- 4〜10のソースを使用する
- それらのソースで表現される多様な基準クロックがあることを確認してください
- 認証されていないリモートコントロールを許可しない（ほとんどのディストリビューションではデフォルトにする必要があります）
- 責任を持ってプールを使用してください（ほとんどのディストリビューションではデフォルトでもあります）
- うるうにじみのあるソースとうるうにじみのないソースを混在させない
- 認証されていないブロードキャストモードを使用しない
- 時間を提供しているときにエニーキャストや負荷分散を使用しないでください
測定場所
ローカル構成が適切になったら、リモートサーバーからのオフセットを手動で測定するのではなく、メトリックがローカルNTPサーバーにクエリする必要があることを覚えておいてください。主要なNTPサーバー（ntpdおよびchronyd）は、必要なすべてのメトリックを既に収集しているため、リモートサーバーとクロックを比較するチェックでは、NTPに組み込まれている多くの利点が無視されています。
メトリック選択
したがって、あなたの質問に対して、あなたが最も関心を持つべきメトリックは次のとおりです：
- システムオフセット：ローカルクロックの1つの真の時間からのオフセットの計算された最良の推測
- ルート分散：層0ソースからのローカルクロックの計算された最大オフセット
モニタリング
NTPにはいくつかの監視ソリューションがあります-既に行っている監視によっては、他の監視ソリューションよりも適切な監視ソリューションがあります。これらの概要を my blog に書きました、これが要約です：
- ナギオス：
- check_ntp_peer：まともな基本チェック。十分に広い範囲の指標をチェックしません。それが許すオフセットでは少し自由主義
- check_ntp_time：推奨されません。指定されたリモートNTPサーバーからのオフセットのみをチェックします
- check_ntpd：妥当なチェックカバレッジ。 PythonよりもPerlを好む場合に使用します。
- ntpmon のnagiosチェック
- collectd：
- prometheus/influxdb
- prometheusノードエクスポーター ：推奨されません。指定されたリモートNTPサーバーからのオフセットのみをチェックします
- telegraf ntpq input plugin ：ntpq出力のテレグラフメトリックへの直接変換。 「私のNTPサーバーは大丈夫ですか？」
- ntpmon テレグラフモード
注意事項
- 上記は、私がアラートとテレメトリレビューを行った2016年10月の状態の要約です。それ以来、状況は改善している可能性があります。
- ntpmon は、当時利用可能だったチェックの不備を克服した私のプロジェクトです。 ntpdとchronydの両方、および上記のアラートおよびテレメトリシステムをサポートしています。
確かに、標準的なアプローチは、バンドルされたNTPクライアントと呼ばれるntpqを使用することです。このユーティリティを使用して、接続されているサーバー、その到達可能性、時間差、ジッターを表示できます。次に例を示します。
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*metasntp12.admi .MRS. 1 u 274 1024 377 64.445 1.086 0.450
+cecar.ddg.lth.s 130.149.17.8 2 u 811 1024 377 48.143 -0.810 0.175
dir.mcc.ac.uk 85.199.214.100 2 u 7d 1024 0 76.708 -1.654 0.000
ここでは、3つのサーバーが構成されており、2つは大丈夫です（377の到達可能性はバイナリ11 111 1111に拡張され、1は成功した応答、0は応答がないことを意味するため、377は100％の到達可能性を意味します）。なんらかの理由。オフセットはミリ秒単位の時間オフセットを表し、ジッターは変動性です。