序論
サービス・チェックの基本的な作業はここで説明されます…
サービス・チェックはいつ実行されますか?
サービスはNagiosデーモンによってチェックされます:
オンデマンド・チェックは、サービス依存予測チェック・ロジックの一部として実行されます。 これらのチェックは、依存論理ができるだけ正確に確認するを助けます。 サービスの依存を利用しないと、Nagiosはどんなオンデマンド・サービス・チェックも実行しません。
キャッシュ・サービス・チェック
オンデマンド・サービス・チェックの性能は、キャッシュチェックを使うことで劇的に改善されます。それはＮａｇｉｏｓにサービスチェックを実行する代わりに比較的 新しい結果を使うことです。 サービスの依存を利用している場合にだけ、キャッシュされたチェックは性能が良くなります。 ここでキャッシュされたチェックに関する詳しい情報を見つけることができます。
依存とチェック
Nagiosが他の1つ以上の他のサービス状態に依存するサービス状態をチェックを避ける定義が サービス依存関係定義でできます。 ここで依存に関する詳しい情報を見つけることができます。
サービス・チェックの並列化
定期的なサービスチェックは並行処理されます。 Nagiosが、定期的にチェックを走らせる必要があると、サービス・チェックを開始して、その後戻って他の仕事を実行します(実行中のホスト・チェックなど) サービス・チェックはNagiosデーモンからフォーク()された子プロセスとして動きます サービスチックが終われば、子プロセスは親プロセスにチェック結果を知らせます。 主なNagiosの処理は、次に、チェック結果に対して、適切な処理をします。(イベントハンドラ実行、通告など)。
オンデマンドサービス・チェックもまた、必要であるなら、並行処理します。 先に述べたように、比較的最近のサービス・チェックをキャッシュされた結果として使用できるなら、Nagiosはオンデマンドサービス・チェックの実際の実行を止めることができます。
サービス状態
チェックされるサービスは4つの異なった状態の1つを取ることが出来ます:
- OK
- 警告
- 未知
- 重大
サービス状態の決定
サービス・チェックはプラグインによって実行されます。(プラグインはOK、WARNING、UNKNOWN、またはCRITICALの状態を返すことができます)。 これらのプラグイン状態は直接サービス状態に変換されます。 例えば、WARNING状態をプラグインが返すと、サービスには、WARNING状態になります。
サービスの状態変化
Nagiosがサービスの状態をチェックするとき、それは、サービスがいつOKと、WARNINGと、UNKNOWNと、CRITICAL状態の間が変化するかを検出して、適切な処理をすることができます。 これらの状態変化の結果は異なった状態タイプ（ＨＡＲＤかＳＯＦＴ）があり、これを引き金とてイベントハンドラーの実行、通知を行います。 また、サービス状態の変化はオンデマンドの ホスト・チェックの引き金となります。 状態の変更を検出し対処することは、Nagiosが行っている全てです。
サービスがあまりに頻繁に状態を変えるなら、「バタツキ」と考えられます。 Nagiosはサービスが何時バタツキを始めるたかを検出でます。そして、バタツキが止まって、サービスの状態が安定するまで、通知を抑圧できます。 ここでバタツキ検出ロジックに関する詳しい情報があります。
参照: