サービスチェックのソースを表示

== 導入 Introduction ==
サービスチェックの基本的な作業はここで説明されます…。 


== サービスチェックはいつ実行されるのか? When Are Service Checks Performed? ==
サービスは、nagiosデーモンによってチェックされる: 
*あなたの[[サービス定義]]における check_intervalとretry_intervalオプションによる定義と同じ、一定の間隔。 
*予報サービスの依存チェック の必要があれば要求に応じて。 

要求に応じてのチェックは[[予報サービスの依存チェック]]の論理の一部として実行されます。これらのチェックは、依存の論理が確実にできるだけ正確になるようにするのを助けます。あなたが[[サービスの依存]]を利用しないのなら、Nagiosはどんなオンデマンドサービスチェックも実行しないでしょう。


== キャッシュされたサービスチェック Cached Service Checks ==
オンデマンドサービスチェックのパフォーマンスは、Nagiosが比較的最近のチェック結果を代わりにすることを決定するなら、サービスチェックを実行するのを差し控えることが出来る、キャッシュされたチェックの使用を実行することによって、かなり向上出来ます。キャッシュされたチェックは、あなたが[[サービスの依存]]を利用している場合にだけ性能増加を与えます。 [[ここ]]でキャッシュされたチェックに関する詳しい情報を見つけることが出来ます。 


== サービスの並列化チェック Parallelization of Service Checks ==
スケジュールされたサービスチェックは、並行して動きます。 Nagiosがスケジュールされたサービスチェックを実行する必要がある時、サービスチェックを開始して、次に、他の仕事に戻るでしょう(running host checksなど)。サービスチェックは主なNagiosデーモンから分岐した子プロセスにおいて実行されます。サービスチェックが完了した時、子プロセスはチェック結果についてメインのNagiosプロセス(その親)に知らせるでしょう。メインのNagiosプロセスはその時、チェック結果を扱って適切な行動を取ります(通告を送る、イベントハンドラの実行、など)。 

オンデマンドサービスチェックもまた、必要であるなら並行して実行されます。先に述べたように、比較的最近のサービスチェックからキャッシュされた結果を使用できるなら、 Nagiosはオンデマンドサービスチェックの実際の実行を見合わせる事が出来ます。 


== サービス状態  Service States ==
チェックされるサービスが4つの異なった状態の1つになることができます: 

*OK
*WARNING
*UNKNOWN
*CRITICAL


== サービス状態の決定 Service State Determination==
サービスチェックは[[プラグイン]]によって実行されます。それはOK、WARNING、UNKNOWN、またはCRITICALの状態に戻すことができます。これらのプラグイン状態は直接、サービス状態に解釈されます。例えば、WARNING状態に戻るプラグインには、WARNING状態があるサービスに起因するでしょう。 


== サービス状態変更 Services State Changes ==
Nagiosがサービスの状態をチェックするとき、サービスがOK、WARNING、UNKNOWN、CRITICALの状態の間で変化し、適切な行動を取る時、それは検出できるでしょう。これらの状態変更は異なった、実行されるべき[[イベントハンドラ]]と[[通知]] のきっかけとなることが出来る [[状態のタイプ]](HARDかSOFT) をもたらします。また、サービス状態の変化は、要求に応じて[[ホストチェック]]のきっかけとなることが出来ます。状態変更を検出して対処するのが、Nagiosに関する全てです。

サービスがあまりに頻繁に状態を変える時「flapping(ばたつき)」していると考えられています。 Nagiosはサービスがいつflappingし始めるかを検出出来て、 flappingが止まって、サービスの状態が安定するまで、通知を抑えることが出来ます。 [[ここ]]でフラップ検出論理に関する詳しい情報を見つけることが出来ます。