Nagiosの困ったこと紹介

本日はNTPサーバの監視についてのちょっと困った事を記載します。
あまりNTPサービス監視というと重要視されていない項目の１つだと思います。
そもそも現代で、時間が大幅に狂うという事自体が少なくなってきました。
最近ではRHEL6になってntpd起動前にntpdateを自動で実行してくれるような
仕様になったりして、昔のようにcrondに時刻修正のコマンド設定をしなくても
良くなっている事も1つの要因かもしれません。

さて話を戻しますが、今回ntpサービスの監視で困った事とは、ずばり
「時刻同期」の監視です。下はサーバで時刻同期状態の結果ですが。
ここで注目すべきは、３つのフィールド（poll、reach、offset）です。

poll フィールドは、NTP ポール パケット間のポーリング間隔（秒）を表します。
NTP サーバとクライアントとの同期が良好で、損失パケットがないと、
この数値は最大 1,024 まで増大します。

offset フィールドは、クライアントの時刻とサーバの時刻から
算出されたオフセット（ミリ秒単位）です。

reach フィールドはビットの循環バッファです。このフィールドは、
最後の8つのNTPメッセージのステータスを示します。（8 ビットは 8 進法で
377 なので、reachフィールドの値は 377 であることが望まれます）
NTP 応答パケットが失われた場合、その後8回の NTP 更新にわたって reach
フィールドにパケット損失の痕跡が残ります。

なお一番最初の＊や＋が、NTPサーバとの関係を示しています。
*は、現在同期中のサーバーです。
+は、 参照可能なサーバーです。

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+the.platformnin 157.XXX.XX.139 3 u 55 1024 377 2.853 -0.939 3.274
-routerida1.sopr 133.XXX.XXX.244 2 u 67 1024 377 11.670 -6.436 10.489
+219x123x70x90.a 192.168.XX.177 3 u 35 1024 377 2.082 -0.506 1.481
*219x123x70x92.a 192.168.XX.123 2 u 456 1024 377 3.309 -0.281 1.834

上記の仕様を鑑みるとNTPサーバとクライアントの同期が良好ですと、
ポーリング間隔が長くなるので、仮にNTPサーバがダウンすると、NTP時刻の
同期時刻ずれ（offset）を監視していた場合は、最大で1024（秒）X　対象
のNTPサーバが時刻更新対象から外れるまでのreach（回数）の間、
NTPアラートが継続するのです。弊社の技術者の検証では、対象のNTPサーバが
時刻更新対象から外れるまでのreachは5回か6回が多かったそうです。
1時間近くアラートが解消されないケースがNTPサービスではありえるという
お話でした。

※NagiosでNTPを監視するプラグインには大きく2種類あります。

check_ntp_peer・・・監視対象ホストと監視対象ホストが参照している
NTP サーバとのoffsetを監視する。今回の上記のケースだと相手先の
NTPサーバが落ちていた場合、この方式だと最終同期時のoffsetを参照する
ため、気付きにくい。

# ./check_ntp_peer -t 10 -H localhost -w 1 -c 1
NTP OK: Offset 0.000281 secs|offset=0.000167s;1.000000;1.000000;

check_ntp_time・・・監視対象ホストと監視サーバ
（check_ntp_time を実行する機器）とのoffsetを監視する。

# ./check_ntp_time -t 10 -H localhost -w 1 -c 1
NTP OK: Offset -3.933906555e-06 secs|offset=-0.000004s;1.000000;1.000000;