サービス A では、Rtr_1 と Rtr_2 の 2 つのルータが監視されます。Rtr_1 または Rtr_2 のいずれかが稼働している場合、サービス A は機能しますが、両方のルータがダウンしている場合、サービス A は機能しません。サービス A では、サービスの監視に「Contact Status Low Sensitivity」ポリシーが使用されます。

このポリシー ルール セットでは、以下のことが規定されています。

 

サービス A では、Rtr_1 および Rtr_2 が適切に監視されているようにみえますが、よく見ると、サービス A の実際の継続性の判断には不十分なようです。サービス A がルータに依存しているだけでなく、特定のルータ ポートに依存している場合はどうでしょうか。接続ステータスのポリシーで監視されるのは、ルータが稼働しているかダウンしているかだけです。

サービス A が依存するポートが同時に使用できない可能性がある場合でも、ルータの接続ステータスが確立されることがあります。このポリシーで対象とされる監視の範囲が制限されているため、サービス A は、実際には実行不可であっても、実行可能であるように見えます。サービス A では、さらに厳密なリソースの監視方法がリソース監視で提供される必要があります。

ポリシーの実装を精査すると、サービス A をサポートしているルータ ポートのステータスを監視していないことがわかります。ルータの接続ステータスと共に、ポートも監視する必要があります。さらに、サービス A が最適に機能するためには、各ルータのポート 4 および 5 が使用可能である必要があります。また、サービス A が適切に機能するためには、4 つのポートのうち少なくとも 2 つが使用可能である必要があります。

サービス A のリソースとして次の 2 つのリソース監視を作成できます。

したがって、ルータ接続リソース監視とポート ステータス リソース監視は、サービス A のリソースということになります。Rtr_1 および Rtr_2 がルータ接続リソース監視のリソースになります。各ルータのポート 4 および 5 は、ポート ステータス リソース監視のリソースということになります。

サービス A は、サービス ヘルス - 高感度ポリシーを使用して、ルータ接続リソース監視およびポート ステータス リソース監視のサービス ヘルス属性を監視します。このポリシー ルール セットでは、以下のことが規定されています。

したがって、いずれか 1 つのリソース監視がダウンした場合、サービス A はダウンします。

 

サービス A を精査すると、その機能には、データベース サーバの応答性および FTP の転送時間が重要であることがわかります。CA Spectrum の 2 つの RTM_Test モデルが、データベース サーバおよび FTP サーバへのレスポンス時間の重大、メジャー、およびマイナーのしきい値を定義すると仮定します。これらのテストは、サービス A の別のリソース監視となる別のリソース監視（レスポンス時間リソース監視）のリソースになることができます。

レスポンス時間のリソース監視では、レスポンス時間 - 高感度ポリシーを使用して、レスポンス時間のテストが監視されます。このポリシー ルール セットでは、以下のことが規定されています。

したがって、このリソース監視でダウンが報告された場合（いずれかのテストで、レスポンス時間について許容できない遅延が示された場合）には、サービス A のすべてのリソース監視を監視しているサービス ヘルス - 高感度ポリシーで規定されているように、サービス A がダウンします。

 

アクティブ状態および保守モード状態にある複数のサービスに対してリソース監視を使用する場合、以下の属性により、保守モードのサービスのリソース監視動作を管理できます。

例：

RollMaintenanceToResourceMonitor 属性値を［はい］（デフォルト値）に設定した場合

アクティブなサービスから保守モードのサービスにリソース監視を追加すると、そのリソース監視は使用されているすべてのサービスで保守モードに変わります。

RollMaintenanceToResourceMonitor 属性値を［いいえ］に設定した場合

アクティブなサービスから保守モードのサービスにリソース監視を追加すると、そのリソース監視はすべてのサービスで保守モードに変わりません。リソース監視は、他のアクティブなサービスでは引き続きその状態であり続けます。