ホストとサービス依存関係は、ホストやサービスに関する明らかに無意味なチェックの実行や通知を行わないことで、リソースの節約に役立ちます。依存関係は、他のひとつ以上のホストやサービスのステータスに基づいてサービスをコントロールできるようにします。
監視対象の機器が監視サーバと同じサブネット上にない場合、監視はその間にあるスイッチやルータに依存します。たとえば、 Monitor3 上のサービスが赤に変わったら、あなたは通知が行われるべきだと考えるかも知れません。しかし、幸いなことに監視システムはそれよりも慎重です。 Monitor3 上のサービスが赤に変わったら、何らかの通知を送る前に、監視システムはホスト自体、つまり Monitor3 のホスト Server2 に ping を送出します。そのホストが ping に応答しなければ、監視システムは上流でもっとも隣接したスイッチ Switch2 に ping を送出します。もし Switch2 が応答しなければ、次に上流の機器、つまり Router2 というように続けます。
このやり方では、システムは根本原因箇所を特定しようとして依存関係のツリーを移動します。推定されたら、システムは、根本原因についての単一の通知を送出し、この遮断型の停止によって「赤」になろうとしている数百あるいは数千もの下流のサービスについての通知を抑制します。このタイプの依存関係は、物理的ネットワーク構造に依存するので、物理依存性と呼びます。物理依存性は、ホストのレコード内の Parents(親ホスト)ディレクティブで定義されます。
また、他の依存関係もあります。
図の Monitor1 は、まったく分かれたネットワーク上にあるデータベースサーバに依存するアプリケーションサーバとします。これは、論理依存性といいます。論理依存性は、ホストレーコード内の Host Dependency(ホスト依存)ディレクティブで定義されます。
三番目のタイプの依存性として、サービス依存があります。たとえば SNMP を使って Cisco ルータの数百のポートを監視するあるホストを監視するためにエージェントを使用する、たとえば SNMP を使って Cisco ルータの数百のポートを監視する場合、 SNMP ービス稼動の独立したチェックが設定されます。たとえば、 Cisco ルータの IOS バージョンを返すよう SNMP に依頼するかもしれません。そうすると、数百ものルータ内のポートチェックすべてが、この独立した SNMP 機能のチェックに依存させることができます。こうして、ルータ上の NMP エージェントが応答しなくなった場合、ひとつの通知のみを受け、数百の他の偽の通知は自動的に抑制されるでしょう。
GroundWork Monitor の標準の依存関係には、上流のスイッチやルータの監視、ホスト上のサービスステータスとポートベースの監視エージェントの稼動が含まれます。
下記のリンクは、親子関係、サービスとホストに依存関係定義を含む、さまざまなタイプの依存関係を説明します。また、構成設定の実施シナリオのリストに戻るには、ホームアイコンを選んでください。