アラートインパクトカリキュレーション
インパクトカリキュレーションでは、CI、サービス、アラート、およびアラートグループの機能停止の規模が示されます。生成されたアラートの重大度の計算には、影響度ルールや CI 関係などのファクターが使用されます。重大度は、影響ツリー、アプリケーションサービスマップ、およびダッシュボードに表示されます。
- 影響度ルール。
- 関連するアクティブなアラートの数。
- 影響を受ける CI の過去の履歴。
- 特定のアプリケーションサービスまたはアプリケーションサービスの CI 間の関係。
- CI 要素にネットワークまたはストレージデバイスが含まれている場合。
- メンテナンスステータス内の CI のアラートは、インパクトカリキュレーションから除外されます。注:
- CI は、アクティブな変更要求がスケジュールされている場合だけでなく、CI の [ステータス] フィールドが [メンテナンス中] に設定されている場合にも、メンテナンス中であると見なされます。
- 子 CI がメンテナンス中になると、親 CI もメンテナンス中になります。
サービス間に接続が存在する場合は、一方のサービスに対する他方のサービスの影響度も計算されます。
インパクトカリキュレーションの方法
インパクトカリキュレーションは、1 つまたは複数のアプリケーションサービスの CI 関係によって異なります。変更要求、ネットワークパス、ストレージパス、関連する CI などの他のファクターすべてがインパクトカリキュレーションを左右します。
- サービス
- 次のインパクトカリキュレーションフローは、機能停止がネットワークまたはネットワークストレージに影響しないアラートの場合に動作します。イベント管理 で次の手順が実行されます。
- サービスマップを作成します。サービス構成アイテムの関連性 [svc_ci_assoc] テーブルと CI 関係 [cmdb_rel_ci] テーブルを使用して、特定または複数のアプリケーションサービスの親子関係を作成します。
- サービスから CI への CMDB パスがなくても [svc_ci_assoc] テーブルに関連性が表示される場合は、アプリケーションサービスと CI の間の依存関係を示します。それ以外の場合、接続は表示されません。
- アプリケーションサービスでは、サービスにアサインされた CI が CMDB 内のサービスにも接続されている場合、マップは、CMDB に存在しているとおりに CI 間の階層を保持します。CI サービスアサインメントは、 アプリケーションサービスフォームの [サービス構成アイテムの関連性] セクションに表示されます。CMDB 内のサービスへの接続がない場合、CI はマップ内のアプリケーションサービスの直下に表示されます。
- 影響ツリーを作成します。機能停止の規模を、100% ダウン、60% に影響、40% の機能障害、または 20% の機能障害としてマークします。2 つ以上のクラスター内のアイテムが影響を受けると、影響度は 100% ダウンとなります。
- 変更要求および「メンテナンス中」ステータス
CI に対してアクティブな変更要求がスケジュールされている場合、または CI の [インストールステータス] が [メンテナンス中] の場合、影響を受ける CI のすべてのアラートがインパクトカリキュレーションから除外されます。また、[アラート] タブでは、対応するすべてのアラートが一時的に非表示になります。影響度ツリーには、(メンテナンス中) というメモとともに CI が緑色で表示されます。影響度ツリーとサービスマップには、一時的に CI が緑色で表示されます。
注:- CI は、アクティブな変更要求がスケジュールされている場合だけでなく、CI の [ステータス] フィールドが [メンテナンス中] に設定されている場合にも、メンテナンス中であると見なされます。
- 子 CI がメンテナンス中になると、親 CI もメンテナンス中になります。
サービスの場合、サービスの CI ではすべてのアラートも [アラート] タブで非表示になります。サービス全体は影響度ツリーに緑色で表示されます。アクティブな変更要求があるホストの場合、ホストアプリケーションは 1 つのユニットと見なされます。すべての子アプリケーションは、変更要求がアクティブでなくなるまでホストと同じ方法で処理されます。 詳細については、「メンテナンス中の CI でのアラートの動作」を参照してください。
- ネットワークパス
- ネットワーク冗長性を考慮するために、イベント管理 では個別のインパクトカリキュレーションを使用します。ネットワークトポロジまたはパスの変更は、アプリケーションサービスで確認できます。次のインパクトカリキュレーションフローは、ネットワークパスが影響を受けるアラートの場合に動作します。イベント管理 で次の手順が実行されます。
- 影響を受けるネットワークのアプリケーションサービスマップを作成します。
- アラートからのホスト ID とターゲット IP 情報、およびネットワークパス [sa_network_paths] テーブルからのネットワークパスを使用します。
- 構成アイテム [cmdb_ci] テーブルから派生したネットワークパス内の要素を使用します。また、要素へのインフラパス [sa_infra_path_assoc] テーブルからの、パスに関連付けられている要素を使用します。
- 関係性を設定します。アプリケーション CI は、CI 関係 [cmdb_rel_ci] テーブルに定義されている、パス内の要素に対する Depends on::Used by 関係を保持しています。関係性では、アプリケーション CI が親であり、ネットワークパス内の要素が子となります。
- パス内の通常の要素ごとに個別の重大度を計算します。パス内の通常の要素はそれぞれ、パスの派生元であるアプリケーション CI に遡るまで、その先祖に対して要素自体の重大度を提供します。
- 影響を受ける CI の重大度を 1 レベル減らすことで、冗長性ルールを使用して、パス内のすべての冗長要素を計算します。たとえば、重大度が「Critical」の場合、冗長性ルールにより重大度が「Major」へと 1 レベル下げられます。
- 影響ツリーを作成します。機能停止の規模を、100% ダウン、60% に影響、40% の機能障害、または 20% の機能障害としてマークします。2 つ以上のクラスター内のアイテムが影響を受けると、影響度は 100% ダウンとなります。
- 影響を受けるネットワークのアプリケーションサービスマップを作成します。
- ストレージパス
- ストレージデバイス冗長性を考慮するために、イベント管理 では個別のインパクトカリキュレーションを使用します。ネットワークストレージトポロジが変更されたときの、影響ツリーの更新は、アプリケーションサービスから確認できます。ストレージ CI を含むアラートに対して、イベント管理 は次の手順を実行します。
- 影響を受けるストレージデバイスの、アプリケーションサービスマップを作成します。
- sa_fs_to_storage_path テーブルのストレージデバイスを使用します。ストレージデバイス定義では、パス内のファイルシステム情報を使用します。
- 構成アイテム [cmdb_ci] テーブルから派生したストレージパス内の要素を使用します。また、要素へのインフラパス [sa_infra_path_assoc] テーブルからの、パスに関連付けられている要素を使用します。
- 関係性を設定します。アプリケーション CI は、CI 関係 [cmdb_rel_ci] テーブルに定義されている、パス内の要素に対する Depends on::Used by 関係を保持しています。関係性では、アプリケーション CI が親であり、ストレージパス内の要素が子となります。
- パス内の通常の要素ごとに個別の重大度を計算します。パス内の通常の要素はそれぞれ、パスの元のアプリケーション CI に遡るまで、その先祖に対して要素自体の重大度を提供します。
- 影響を受ける CI の重大度を 1 レベル減らすことで、冗長性ルールを使用して、パス内の冗長要素を計算します。たとえば、重大度が「Critical」の場合、冗長性ルールにより「Major」へと 1 レベル下げられます。
- 影響ツリーを作成します。機能停止の規模を、100% ダウン、60% に影響、40% の機能障害、または 20% の機能障害としてマークします。2 つ以上のクラスター内のアイテムが影響を受けると、影響度は 100% ダウンとなります。
- 影響を受けるストレージデバイスの、アプリケーションサービスマップを作成します。
- 関連 CI
CI のアラートが生成されると、関連 CI に対して追加のインパクトカリキュレーションが実行されます。たとえば、実際にアプリケーションサービスに含まれていない CI に対するアプリケーションサービスの依存関係について、追加のインパクトカリキュレーションが実行されます。こうした関連 CI は、サービスの一部としては検出されません。代わりに、関連 CI はインフラストラクチャ関係定義によって指定されます。
次のインパクトカリキュレーションフローは、アプリケーションサービスに含まれていないと見なされる関連 CI に依存する CI を伴うアラートに対して動作します。イベント管理 は次の手順を実行します。- アプリケーションサービス CI と関連 CI の関係性を導出します。インフラストラクチャ関係 [em_impact_infra_rel_def] テーブルの関係、影響度ルール、およびその他のデータを使用します。
- イベント管理 ダッシュボードの影響ツリーとアラートリストに関連 CI を追加します。
- インフラストラクチャ関係 [em_impact_infra_rel_def] テーブルのデータを使用して、ホストへの格納リンクを表示します。
- 影響ステータス [em_impact_status] テーブルとアラート履歴 [em_alert_history] テーブルを使用して、ステータスを決定します。
影響度ルール
インパクトカリキュレーションに使用されるインパクトルールでは、影響を受ける CI に基づいて機能停止の規模または重大度を推定します。- アプリケーションクラスタメンバー
- アプリケーションのクラスターメンバーがクラスターの全体的な影響にどのように関与するかを決定します。たとえば、3 つのメンバーがあるクラスターで [90% 影響 (90% Influence)] をクラスター全体の重大度 [メジャー] に設定する必要がある場合、各メンバーの影響度は [30% 影響 (30% Influence)] (90% を 3 で除算) になります。3 つのメンバーすべての重大度が [メジャー] である場合にのみ、クラスター全体の重大度を [メジャー] に変更できます。 クラスターごとに異なる影響度ルールを構成できるため、子 CI から親 (同じ子 CI に対する) への影響度伝達が異なります。したがって、CI のグループを手動で作成し (別名：手動クラスター)、クラスターの子に向かう下流に対するクラスターレベルで影響度ルールを構成できます。
図 : 2. 同じ子 CI から親クラスターへの影響を各クラスターに異なる方法で伝達する例 上記の例では、エントリーポイントが 2 つあります。右側の Osaka クラスターには 3 つの CI があります。左側の Tokyo クラスターには 2 つの CI があります。Tokyo and Osaka バックアップサーバーは共有の親があります。Tokyo クラスターと Osaka クラスターです。右側のパネルには影響ツリーが表示され、Tokyo クラスターの 2 つのアプリケーションクラスターメンバーはそれぞれ影響度が 50% で、Osaka クラスターの 3 つのメンバーはそれぞれ 34% の影響度を持っています。
手動クラスター構成の場合、[アプリケーション影響] と [アプリケーションクラスタメンバー] の 2 つの行があります。[影響度 (Impact On)] フィールドで [アプリケーションサービス] ではなく [親] が選択されているため、子が表示されます。[アプリケーションクラスタメンバー] 行で [影響] フィールドが 2 に構成されています。これは、失敗する (および失敗を親に伝達する) 子の最小数が 2 つであることを意味します。Osaka クラスターでは 3 に構成されています。それぞれのクラスターでの Tokyo and Osaka バックアップサーバーの影響割合は異なります (50% と 34%)。ご覧のとおり、Tokyo and Osaka バックアップサーバーの障害は赤で重大ですが、親への影響は異なります。Tokyo クラスターの障害はオレンジ色で大になりますが、Osaka クラスターは緑色のままです。
サービスまたは CI をクリックすると、それに関連付けられているアラートが表示されます。たとえば、高レベルのアプリケーションサービスをクリックした場合、[アラート] を選択するとそれに関連付けられているアラートがマップビューの下にあるアラートエリアに表示されます。一覧表示されるのは、選択したサービスのアラートです。そうしたサービスを選択すると、子サービスのアラートが一覧表示されます。
[影響度] を選択すると、次の影響度フィールドが表示されます。
- 包含
- 包含関係のあるエンティティへの影響を決定します。このルールは読み込み専用です。
- インフラストラクチャの依存関係
- インフラストラクチャ関係内の CI に対する影響度伝達の定義を決定します。
- CI アプリケーションサービス
- アプリケーションサービスの一部である親または子エンティティに影響を与える方法を決定します。
- CI 影響
- アプリケーションサービスに適用します。サービスメンバー間の関係を決定します。子 CI から親 CI への影響は常に 100% です。たとえば、親の影響度の重大度は、重大度が最大の子 CI から派生します。
- アプリケーション内の CI 親
- 親エンティティにのみ影響を設定します。
- ネットワークパス
- 従来のネットワークの一部である親または子エンティティにどのように影響するのかを決定します。
- OS クラスタメンバー
- クラスターメンバーの割合または数に基づいて、ホストクラスターメンバーがクラスター全体のステータスどのように影響するかを決定します。たとえば、3 つのホストがあるクラスターで [60% 影響 (60% Influence)] を重大度 [メジャー] に設定する必要がある場合、各メンバーは [20% 影響 (20% Influence)] (60% を 3 で除算) になります。2 つ以上のクラスターメンバーの重大度が [メジャー] である場合にのみ、クラスター全体の重大度を [メジャー] に変更できます。クラスター全体も停止していると見なされます。
- ストレージパス
- ストレージネットワークの一部である親または子エンティティにどのように影響するのかを決定します。
プロパティ
インパクトルールの設定に加えて、インパクトカリキュレーションのプロパティを設定することもできます。| プロパティ名 | 説明 |
|---|---|
evt_mgmt.impact_calculation.alert_group_support |
アラートグループのサポートを有効化します。 |
evt_mgmt.impact_maintenance.sleep_time_sec |
CI のメンテナンスをチェックする最小時間 (秒)：CI の [ステータス] フィールドと CI に対する変更要求スケジュールの両方がチェックされます。 |
evt_mgmt.impact_calculation.alert_copy_delay |
アラートが作成または更新されてから、インパクトカリキュレーションとグループ化に使用されるまでの遅延。em_alert テーブルで定義された到着の遅れや遅いビジネスルールを補うために使用されます。デフォルトは 2,000 ミリ秒です。 アラートとイベントが一度に 1 つずつ処理される ( |
evt_mgmt.impact_calculation.alert_copy_delay_when_alerts_are_processed_in_batch_msec |
アラートが作成または更新されてから、インパクトカリキュレーションとグループ化に使用されるまでの遅延。em_alert テーブルで定義された到着の遅れや遅いビジネスルールを補うために使用されます。デフォルトは 30,000 ミリ秒です。 トラフィックが多い大規模な顧客の環境で、アラートとイベントがバッチで処理される ( |