リソースの欠落、および分離が十分でないリソースにより、あってはならない場合に「稼働」というヘルスを示すサービスがしばしば発生します。論理的に起こりえない場合に、サービス モデルが「ダウン」または「低下」というヘルスを示すこともあります。これは、リソース障害に影響を与える非サービスと表現することができます。

この種の問題を生成する一般的な 2 つの状況がありますますが、これは 2 つとも異なっています。

最初の状況は、リソース モデルのステータスが関連する子モデルによって影響を受ける場合です。このような状況は、論理的にはサービス リソースであるけれども、他のモデルの影響を受けるスタータスを持つモデル（つまりサービス リソースでないモデル）を選択した場合に発生することがあります。たとえば、ネットワーク デバイスを、実際にサービスをサポートするインターフェースではなく、特定のサービスのリソースとして指定する場合などです。別の例として、ホスト モデルまたはサーバを処理して、ホスト自体が（監視対象のプロセスやファイル システム モデルではなく）失敗したプロセスまたはファイル システムに対してアラームを発行する場合があります。プロセスまたはファイル システムが論理的に特定のサービスの一部でない場合、サービスは影響を受けるヘルスを示してはならないにもかかわらず、影響を受けるヘルスを示すことがあります。このような状況は、サービス リソースとして最も適切なモデル（特定のインターフェースや管理プロセスなど）を選択することにより、簡単に解決できます。

2 番目の状況は、サービスがそのリソース モデルの「状態」を監視する場合に排他的に発生します。リソース モデルの「状態」は、モデル上の最も重大なアラームの値を保持します。CA Spectrum は何千もの種類の異なるアラームを生成します。これらのアラームの一部は障害に影響を与えるサービスを示しますが、多くのアラームは異なります。CA Spectrum はデフォルトで、さまざまな理由からデバイスを監視しますが、基本的にはネットワーク インフラストラクチャの観点からデバイスが正しく機能していることを確認するために監視しています。ネットワーク管理に関連する障害に関するさまざまなアラームを確認できますが、これらのアラームはサービスが監視する機能に対して論理的な影響を持たないことがあります。同様に、指定されたモデルが複数のサービスのリソースとなることがあります。このような場合、特定のアラームが一部のサービスにとって重要であっても、他のサービスにとっては重要でない場合があります。これは、サービスの目的が特定の責任に基づいてコンプライアンスを監視することである場合に、頻繁に発生します。

Service Manager のアラーム タイプ除外機能は、サービス ヘルスに影響を与えてはならないリソース アラームをサポートするために設計されたものです。特定のリソース障害がサービスに影響を与えてはならないことが判明した場合、アラーム タイプ除外構成を指定できます。この設定は個々のサービスやリソース モニタに対して指定することも、動作が共通の場合は、サービス ポリシーで指定することもできます。

アラーム タイプ除外を適用すると、誤ったサービス停止がなくなるため、サービス モデルの正確性をさらに改善できます。