序論
「ストーキング」状態は、多分、ほとんどのユーザでは、使う必要の無い特色です。 許可されると、たとえホストやサービスの状態変化が起こらなくてもサービスとホストチェック出力の変化を記録できます。 ストーキングが特定のホストやサービスに許可されると、Nagiosは非常に慎重にそのホストやサービスを監視し、チェック結果出力で見えるどんな変化も記録します。 分かる様に、それはログファイルの後の解析に非常に役つ場合があります。
どのように働くか?
通常の状況下で、それが最後にチェックされて以降、ホストかサービスが状態が変化した場合だけ、ホストかサービス・チェックの結果が記録されます。 これには幾つかの例外がありますが、大抵、規則が有ります。
特定のホストやサービスの1つ以上のステータスにストーキングを許可すると、Nagiosは、前のチェック出力と違ったチェック出力についてホストやサービス・チェック結果のログを取ります。 8つの連続したサービス・チェックを以下の例に取ります:
| サービス・チェック#: | サービス・ステータス: | サービス・チェック出力: | 通常、登録されます。 | ストーキングの記録 |
|---|---|---|---|---|
| x | OK | RAIDアレイの最適です。 | - | - |
| x+1 | OK | RAIDアレイの最適です。 | - | - |
| x+2 | 警告 | RAIDアレイ低下 (1つのドライブ故障、1つのホットスペアの再構築中) |  | |
| x+3 | 重大 | RAIDアレイ低下 (2つのドライブが故障、1つの予備ホストがオンライン、1つの予備ホストが再構築中 | | |
| x+4 | 重大 | RAIDアレイ低下 (3のドライブが故障、2つの予備ホストがオンライン) | - | |
| x+5 | 重大 | RAIDアレイ故障 | - | |
| x+6 | 重大 | RAIDアレイ故障 | - | - |
| x+7 | 重大 | RAIDアレイ故障 | - | - |
この与えられた一連のチェック、この障害について通常2つの記録しか見ることができません。 x+2 サービス状態がOKからWARNIGに変化した時、最初のサービスチェック x+2 が起こるでしょう。 x+3 サービス状態がWARNINGからCRITICALに変化した時、2番目のサービスのログが記録されるでしょう。
どんな理由でも、あなたはログファイルでこの障害の履歴を記録していたいかもしれません。 おそらく、制御できない状況を如何にすばやくマネージャに説明するのを助けるのは、おそらくまさしく地元のパブの2、3杯飲んでそれを笑う様なものです。…
さて、このサービスのストーキングをCRITICAL状態で許可したなら、x+2ととx+3の出来事に加えてx+4とx+5おイベントが記録されるでしょう。 これはなぜですか? ステータスのストーキングが許可されている状態で、Nagiosは、前のチェック出力と変化しているか確認するためそれぞれのサービスチェック出力を検査がされます。 出力が違っていて、サービス状態が2つのチェックの間で変化しないなら、より新しいサービス・チェック結果は登録されるでしょう。
ストーキングの似た例がウェブサーバーをチェックするサービスかもしれません。check_httpプラグインが最初に、404誤りのためWARNING 状態を返し、その後のチェックで特定のパターンが見つからないためWARNING状態を返すなら、それを知りたいかもしれません。 サービスのWARNINGステータスに状態のストーキングを許可しないなら、最初のWARNINGステータスのイベント(404誤り)だけが登録され、 （ログの記録を見直しても）Webページの応答に何らかのかのテキストパターンが見つからないと言うより何も得られないでしょう。
ストーキングを許可すべきか?
まず最初に、問題の正確な原因を見つけるために記録されたログデータを本当に分析する必要があるかどうか決めなければなりません。 あなたは、いくつかのホストかサービスのためのこの機能が必要と決めますが、すべてのために決めないかもしれません。 また、許可の必要なストーキングが全部でなくあるホストやサービスの状態だけだと分かるかもしれません。 例えば、WARNINGとサービスのCRITICALステータスにストーキングを許可し、OKとUNKNOWNステータスは許可しないかもしれません。
特定のホストやサービスに状態ストーキングを許可の決定は、また、ホストとサービス・チェックのプラグインに依存します。 プラグインがいつも同じテキスト出力を特定の状態で返すなら、その状態にストーキングを許可する理由が全くありません。
どのようにストーキングを許可するか?
ホストとサービス定義中のstalking_option指示を使用してホストとサービスの状態ストーキングを許可する事ができます。
ストーキングと不安定サービスとの違いは?
不安定なサービスも同様ですが、通知とイベントハンドラが実行されます。 ストーキングは純粋に記録目的です。
警告
幾つかの潜在的な落とし穴がストーキングを許可することであることを知るべきです。 これらは全て、様々なCGI(ヒストグラム、警告サマリ)で見ることのできるリポート機能に関連しています。 状態のストーキングはログに追加の警告の残すため、レポートが作るデータは、膨大な数の警告となる場合が有ります。
一般的なルールとして、ホストとサービスのストーキングを良く考えずに許可しないことを提案します。 それでも、必要であり、欲しいと思うなら、そこにあります。
参照: 不安定なサービス