序論
サービスとホストの依存は、1つ以上の他のホストやサービスの状態に基づくホストやサービス動作を制御させるNagiosの高度な特徴です。 ホストとサービスの依存の違いに従って依存がどの様に働くかを説明します。
サービス依存概観
サービスの依存に関して知るべきでいくつかのことがあります:
- サービスは他の1つ以上のサービスに依存している場合があります。
- サービスは同じホストでないサービスに依存している場合があります。
- サービス依存は引き継がれません。 (明確に設定されていない限り)
- サービス依存は、サービス・チェック実行とサービス通知が異なった状況で抑止するのに使用することができます。 (OK、WARNING、UNKNOWN、そして/または、CRITICAL状態)
- サービスの依存は特定の時間範囲だけで有効かもしれません。
サービスの依存を定義
最初に、基礎 オブジェクト設定ファイルにサービス依存定義を加えることで、サービスの依存を作れます。 それぞれの定義では、依存サービス、サービスが依存している、そして依存関係が破れる実行や通知の依存関係が破れる(後で説明)基準(あれば)を指定します。 与えられたサービスに幾つかの依存を作ることが出来ます。しかし、あなたが作るそれぞれの依存について別々のサービス依存定義を加えなければなりません。
サービスの依存例
以下のイメージはサービス通知と実行の依存の例の論理レイアウトを示しています。 通知とチェック実行において、異なったサービスは他のサービスに依存します。
上の例では、Host C のためのサービス F の依存定義は、以下の様に定義されます:
define servicedependency{
host_name Host B
service_description Service D
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria o
notification_failure_criteria w,u
}
define servicedependency{
host_name Host B
service_description Service E
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria n
notification_failure_criteria w,u,c
}
define servicedependency{
host_name Host B
service_description Service C
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria w
notification_failure_criteria c
}
上記のイメージで示された他の依存定義は、以下の通り定義されるでしょう:
define servicedependency{
host_name Host A
service_description Service A
dependent_host_name Host B
dependent_service_description Service D
execution_failure_criteria u
notification_failure_criteria n
}
define servicedependency{
host_name Host A
service_description Service B
dependent_host_name Host B
dependent_service_description Service E
execution_failure_criteria w,u
notification_failure_criteria c
}
define servicedependency{
host_name Host B
service_description Service C
dependent_host_name Host B
dependent_service_description Service E
execution_failure_criteria n
notification_failure_criteria w,u,c
}
サービスの依存はどうテストされるか。
Nagiosがサービス・チェックを実行するか、またはサービスの通告を送る前に、サービスは、どんな依存があるかどうか確認するチェックをします。 それに少しの依存もないなら、通常の様にチェックを実行するか、通知が出されます。 サービスに1つ以上の依存があると、Nagiosは以下それぞれの依存エントリーをチェックします:
- Nagiosは現在の依存しているサービスの状態 * を取得します。
- Nagiosは依存している現在のサービス状態と依存定義の実行や通知の失敗オプションと比較します。(その時、依存していても)
- 現在の依存しているサービス状態が失敗オプションの1つに合っているなら、依存は失敗したと言われます、そして、Nagiosは依存チェックのループから抜け出します。
- 依存している現在のサービス状態が依存エントリーの失敗オプションのいずれとも合わないなら、依存が通ったと言われて、Nagiosは、次の依存エントリーをチェックします。
サービスすべての依存チェックされるか、または1つの依存チェックが失敗するまで、このサイクルは続きます。
注意: 注意する1つの重要なことはデフォルトで、Nagiosが最も現在の安定したサービス状態を使うことです。すなわち、依存チェックをする時、依存するサービスです。 Nagiosにサービス(それが不安定か安定かの状態であるかにかかわらず)の最新状態を使って欲しいなら soft_state_dependencies オプションを許可します。
実行の依存
サービスのアクティブ・チェックがいつ実行するかを制限するのに実行依存は使われます。 パッシブ・チェックは依存の実行によって制限されません。
サービスの実行依存テストのすべてが通ったなら、Nagiosは、通常実行するように、サービスのチェックを実行します。 サービスの実行依存の1つでも失敗すると、Nagiosは一時的にその(依存する)サービスのチェック実行を止めます。 未来のいつかは、サービスの実行依存テストにすべて合格するかもしれません。 これが起こると、Nagiosは、通常の様に再びサービス・チェックを始めます。 チェック・スケジューリング・ロジックに関する詳しい情報をここで見つけることができます。
上の例では、Service BがWARNINGかUNKNOWN状態にあるなら、Service Eは依存実行に失敗するでしょう。 これがそういう場合なら、サービス・チェックは実行されないで、チェックの実行(潜在的)は後に予定されてます。
通知の依存
サービスの通知依存テストすべてが通ったなら、Nagiosは、サービスに通常、通告を送っているように、通知を送ります。 サービスの通知の依存の1つでも失敗すると、Nagiosは一時的にその(依存する)サービスのための通知を止めます。 未来の何らかの点では、サービスの通知依存テストにすべて合格するかもしれません。 これが起こると、Nagiosは、サービスが通常の様に再び警告通知を始めます。 ここで通知ロジックに関する詳しい情報を見つけることができます。
上の例では、Service CがCRITICAL状態で、そして/または、Service DがWARNING UNKNOWN状態、そして/または、Service EがWARNINGにあるか、UNKNOWN、またはCRITICAL状態なら サービス Fは 通知依存に失敗するでしょう。 これがケースであれば、サービスの通知は出されないでしょう。
依存継承
以前言ったように、デフォルトでサービスの依存は引き継がれません。 上の例は、Service FにService Eに依存している事が分かります。しかしながらサービスBとサービスCの依存をサービスEに自動的に引き継ぎません。 サービスFがサービスCに依存させるために他のサービス依存定義を追加しなければいけません。 Service Bの依存定義が全くないので、Service FはService Bに依存していません。
サービス依存を引き継ぎたいなら、サービス依存定義の inherits_parent 定義を使っわなければいけません。 この指示が許可されると依存しているサービスの依存が引き継がれた事を示します。(また、マスターサービスが参照されます) 言い換えれば、マスターサービスが他のサービスに依存していて、それらの依存関係のどれかが失敗すると、この依存関係は失敗します。
上の例では、サービスA に依存する様 サービスF に新しい依存を加えたいと考えます。サービスA (依存されるサービス)がマスターサービスとして サービスF は依存サービスとしての新しい依存指定の定義を作ることができます。 また、サービスDとFの依存定義の別の変更はこの様になります。
define servicedependency{
host_name Host B
service_description Service D
dependent_host_name Host C
dependent_service_description Service F
execution_failure_criteria o
notification_failure_criteria n
inherits_parent 1
}
inherits_parent 定義を 許可されると、Service FとService D間の依存がテストされ、Service AとService D の依存がチェックされるでしょう。
依存は複数レベルの継承を持つことができます。 もし、AとDの間の依存定義がそのinherits_parent定義が許可されサービスAは、他の幾つかのサービス(それを サービスGと呼びます)に依存していると、サービスFはサービスD、A、およびG(潜在的に異なったそれぞれの評価基準がある)に依存しているでしょう。
ホストの依存
たぶん予想されるように、ホスト依存はサービス依存と同じ様に働きます。 違いは、それらがサービスではなく、ホストのためのものです。
チップ: 親/子供ホスト関係とホストの依存を間違ないでください。 ホストの依存よりむしろほとんどのケースに、親/子ホスト関係(ホスト定義における両親の指示で、定義される)を使用するべきです。 ネットワークの可到達性に関するドキュメントで親/子ホスト関係がどう働くかがここに有ります。
ここに、ホストの依存に関する基礎があります:
- ホストは他の1つ以上のホストに依存している場合があります。
- ホストの依存は引き継がれません。 (明確に設定されていない限り)
- ホスト・チェック実行とホスト通知が違った状況で抑止するためにホスト依存を使用できます。 (UP、DOWN、そして/または、UNREACHABLE状態)
- ホストの依存は特定の期間だけ有効かもしれません。
ホストの依存の例
以下のイメージはホスト通知の依存の論理レイアウトの例を示しています。 通知において、違ったホストは他のホストに依存しています。
上の例では、Host Cのための依存定義は、以下の様に定義されます:
define hostdependency{
host_name Host A
dependent_host_name Host C
notification_failure_criteria d
}
define hostdependency{
host_name Host B
dependent_host_name Host C
notification_failure_criteria d,u
}
サービス依存のように、ホスト依存は引き継がれません。 例のイメージで、ホストCは、ホストBの依存を引き継がれない事が分かります。ホストCがホストAに依存するためには、新しいホスト依存定義が必要です。
ホスト通知依存はサービス通知依存と同様に働きます。 ホストの通知依存テストがすべて通ると、Nagiosは、通常の様にホストに通知を送ります。 ホストの通知依存の1つでも失敗すると、Nagiosは一時的にその(依存する)ホストの通知を止めます。 未来のいつかは、ホストの実行依存テストにすべて合格するかもしれません。 これが起こると、Nagiosは、ホストが通常の様に再び警告通知を始めます。 ここで通知ロジックに関する詳しい情報を見つけることができます。