イベント管理 - インパクトカリキュレーションの説明 目次 はじめにインパクトカリキュレーションとはインパクトカリキュレーションの仕組み 1.アラートテーブルからアラート履歴テーブルへのアラートデータのコピー2.コピーしたデータをインパクトカリキュレーションに使用 インパクトカリキュレーションの問題のトラブルシューティング 1.現在のアラートステータスがオペレーターワークスペースに反映されない2.サービスグループジョブが大量のメモリを消費する3.大きい影響度グラフと影響度ステータステーブル4.遅いクエリ5.無効なカスタマイズ トラブルシューティングフロー参照 はじめに この記事は、TSE がインパクトカリキュレーションの機能とそのトラブルシューティングを理解できるようにすることを目的としています。 インパクトカリキュレーションとは ご存知のように、 インパクトカリキュレーションには、CI、サービス、アラート、アラートグループの機能停止の規模が表示されます。したがって、停止が発生した場合のビジネスへの全体的な影響を顧客が理解することが不可欠になります。インパクトカリキュレーションはイベント管理の一部であり、サービスの現在のステータスを確認し、 イベント管理 ➔ オペレーターワークスペースに移動します。 以下はサンプル例です。 ここでは、通常のサービスと影響を受けるサービスを確認できます。影響を受けるサービスのいずれかを開くと、サービス全体が影響を受けるノードを明確に理解できます。 インパクトカリキュレーションの仕組み インパクトカリキュレーションでは、インパクトルールや CI 関係などの要素を使用して、生成されたアラートの重大度を計算します。重大度は、影響ツリー、アプリケーションサービスマップ、およびダッシュボードに表示されます。ここには、主に 2 つのステップがあります。 アラートテーブルからアラート履歴テーブルにアラートデータをコピーしています。インパクトカリキュレーションにコピーされたデータを使用します。 1.アラートテーブルからアラート履歴テーブルへのアラートデータのコピー アラート履歴 [em_alert_history]: OOTB には、スケジュール済みジョブ「イベント管理 - 影響度算出トリガー」があり、このジョブは アラートテーブルからアラート履歴テーブルにデータをコピーし、レコードの [VT_end] フィールドに入力 。アラートテーブルとは異なり、アラート履歴テーブルに同じアラート番号の複数のエントリが表示されることが想定。例:alert0010056。アラートが挿入または更新されるたびに、レコードがアラート履歴テーブルにコピーされます。最新のエントリには、常に将来のアラート有効時刻の終了日が含まれます。したがって、ステータスがオープンで将来の日付であるアラートのエントリがある場合は、アラートによって アクティブな影響 があることを意味します。基本的に、VT END はアラートの有効性を示します。 上の画像を下から上に読んでください。 最初のレコードの [アラートの有効時刻の開始] は 2022-09-08 09:18:49 で アラートの有効時刻の終了は 2022-09-08 09:19:08 です。これは、スクリーンショットのとおりの現在のステータスです。ただし、テーブルの最初のレコードである場合、影響終了時間が不明なため、アラートの有効時間の終了は「8994-08-17 00:12:55」でした。つまり、アラートの影響は 2022-09-08 09:18:49 に開始され、どのくらいの期間続くかはわかりません。影響度をアクティブに保つために、終了日を将来の日付 [~6977 年後] に設定しますしばらくすると、アラートレコードが更新され、コピージョブによって更新されたアラートのコピーが 2022-09-08 09:19:08 にアラート履歴テーブルにコピーされます。これは下から 2 番目のレコードです。これは、アラートの以前のコピーが有効ではなくなったため、前のレコード [下から最初のレコード] の終了時間を 2022-09-08 09:19:08 に設定し、同じ値が 2 番目のレコードの開始時間であることを意味します。一番上のレコードを見ると、開始時間が 2022-09-08 09:19:08 で、どのくらいアクティブになるかわからないため、終了時間を 8994-08-17 00:12:55に設定します。 将来の日付と混同しないでください。それは予想通りです。このアラート履歴データは、特定のサービスに対する CI の影響度を計算するために使用されます。メンテナンスステータスではないアラートについては影響度が表示されます。アラートが既にメンテナンスステータスになっている場合は、影響は表示されません。 アラート履歴テーブルのデータは 3 か月間保存され、30 分ごとに実行されるスケジュール済みジョブ「イベント管理 - アラート履歴テーブルの消去を使用して消去されます。 vt_endが 8994 のイベントは、イベントがまだアクティブであるというステータスを示しているため、クリーンアップされることは想定されません。クリーンアップはvt_start日に基づいて行われます。 注 :オペレーターワークスペースのサービスステータスは アラートテーブルからではなく、アラート履歴テーブルのステータス値を反映しています。 2.コピーしたデータをインパクトカリキュレーションに使用 影響度グラフ [em_impact_graph] インパクトカリキュレーションには、 Impact Graph[em_impact_graph]、 Impact Status [em_impact_status]、および Hashes[sa_hash] の 3 つの重要なテーブルが含まれます。影響ツリービルダージョブ ["イベント管理 - 影響ツリービルダー"]) は、em_impact_changesテーブルの変更を含むすべてのサービスを処理し、影響ツリーを再構築して 11 秒ごとに実行します。レコードは、影響ツリーのビルドの一環としてem_impact_graphに挿入されます。 アラートに依存せず、サービスマッピングトポロジと影響度ルールからビルドされます。影響ツリーには、CI の親子関係に対する影響度ルールの結果が表示されます。このツリーは、サービス構成アイテムの関連性 [svc_ci_assoc] テーブルの CI を含むサービスマップを表しますたとえば、以下の service_v1_40 の例を見ると、これはサービスレコードであり、2 つの CI が 1 つのサービスレコードを指していることがわかります。すべてのレコードのステータスは有効であり、「サービスである」は true と表示されます。 システムがサービスの再構築を試みた場合、またはサービスのステータスを [運用中] >>から [非稼働] >> [運用中] から手動で変更した場合、サービスに関連付けられたすべてのレコードが削除され、ステータスが [有効] の新しいレコードが作成されます。影響度ステータス [em_impact_status]サービスグラフに入力すると、アラートのインパクトカリキュレーション用のジョブが 6 つになります。これらはem_alert_historyとem_impact_graphに基づいています。これらのジョブは、em_impact_statusテーブルのサービスの重大度を計算し、VT 終了フィールドを更新します。ジョブの詳細は次のとおりです。 イベント管理 - BS の影響度算出 [バケット 0-3] - バケット 0 から 3 のサービスの影響度を計算しますイベント管理 - BS の影響度算出 [バケット 2] - アラートグループと SLA。イベント管理:サービスグループへの影響度: サービスグループへの影響度を計算します これらのジョブでは、アラート履歴レコードを使用して em_impact_statusにエントリーを作成します。em_impact_status :データはデフォルトで 3 か月間保存され、CI の重大度ステータスと、CI が含まれるサービスへの影響を反映します。このテーブルはem_alert_historyとem_impact_graphに基づいています。 インパクトカリキュレーションの問題のトラブルシューティング Impact ジョブで観測された上位シナリオは 5 つあります。 現在のアラートステータスは、オペレーターワークスペースには反映されません。サービスグループジョブは大量のメモリを消費します。大きい影響度グラフと影響度ステータステーブル遅いクエリ無効なカスタマイズ 1.現在のアラートステータスがオペレーターワークスペースに反映されない オペレーターワークスペースでアラートステータスの不一致が見つかった場合は、まず以下のテーブルを確認して、問題がどこにあるのかを検証する必要があります。 アラート履歴 [em_alert_history]アラート影響度ステータス [em_impact_status]ハッシュ [sa_hash]アラート履歴ユースケース 1 - アラートデータがコピーされない:アラートがテーブルにコピーされているかどうかを確認する必要があります。これらがコピーされない場合は、コピージョブ「イベント管理 - 影響度算出トリガー)」に問題があることを意味します。アプリケーションノードログとシステムログを確認してジョブの実行を確認し、エラーが報告されているかどうかを確認してください。アラート履歴テーブルへのデータのコピーを開始するには、ジョブを修正する必要があります。ユースケース 2 - アラートデータはコピーされていますが、正しくありません。アラートはコピーされても、レコードの正しいステータスがコピーされないことがあります。これは、低速 BR がコピージョブの実行前にデータを DB にコミットしないことが原因で発生する可能性があります。したがって、カスタム BR が遅いためにアラートレコードの更新が遅れるユースケースに対処するには、次の手順に従います。 evt_mgmt.max_objs_in_alert_query:このプロパティの値が 500 ではなく 1 に設定されていることを常に確認してください。OOTB の場合、値は 1 に設定されます。500 に設定すると、トランザクション内の 500 件のイベントをすべて処理するまで DB に何もコミットしないため、プロセスが遅延します。そのため、処理が迅速に完了するように、イベント を 1 つずつ処理することをお勧めします。evt_mgmt.impact_calculation.alert_copy_delay:デフォルトでは、このプロパティ値は 2 ミリ秒に設定されています。 このプロパティは OOTB には表示されません。ジョブの実行中に、すべてのアラートテーブルで実行されている遅い BR があるかどうかを確認する必要があります。実行されている場合は、evt_mgmt.impact_calculation.alert_copy_delay 値をより高い [デフォルト値 2 ミリ秒] に変更することを検討する必要があります。これにより、ジョブは [now-n] 時間より前に更新されたレコードを考慮するようになります。n はプロパティ値を表します。注:上記の変更を行った後、新しいレコードでは機能しますが、既存のレコードはまだ壊れた状態であるため、既存のデータを処理するには、 KB0826649の手順 3 に従うか、KA に添付されている「emSupport-touchOpenAlertsHistory.txt」スクリプトを実行してください。 別の問題は、誤ったVT END日付です。コピージョブによってこの値が更新されることを認識しています。バックフィルに問題がある場合、このフィールドは更新されません。これは、バックフィルハッシュ値がsa_hashテーブルで同期していないことが原因である可能性があります。 影響度ステータス 影響度ステータスがユーザーの期待を反映していない場合は、影響度グラフテーブルのレコードをチェックして、CI がサービスの一部であるかどうかを確認する必要があります。詳細は上記で説明したとおりです。これとは別に、影響度ステータステーブルの以下の基本的なチェックに従って問題を検証することをお勧めします。 VT 日付の比較:影響を受けると報告されたサービスについて、VT 開始日と VT 終了日が正しく入力されていることを確認してください。上のスクリーンショットの最初のレコードを読むと、「service_v1_179」ビジネスサービスを指す要素識別子として CI「ci_v1_179_1_1」が表示されます。影響は「2022-09-0523:13:44」に始まり、8994-08-17 00:12:55まで続きます。ただし、2 番目のレコードを見ると、同じ CI に対して、影響は「2022-09-05 23:13:37」に開始され、「2022-09-05 23:13:44」に影響度が終了すると言えます。したがって、1 番目と 2 番目のレコードを比較すると、2 番目のレコードから影響は 2022-09-05 23:13:44 に終了したことが確認されますが、最初のレコードの影響はまだアクティブです。上のスクリーンショットは実際の例です。上記の動作に不一致が見られる場合、課題はインパクトカリキュレーションにあります。この場合、基本的なトラブルシューティングとして、運用サービスを非運用状態にして運用状態に戻すことで、既存の影響度グラフをすべて削除して新しい影響度グラフをビルドできます。次に、新しく構築されたエントリが計算に使用されます。 注意: 上記の手順は、根本原因を特定した後にのみ実行してください。根本原因が見つからずにサービスの運用ステータスが変更された場合、将来同様の状況に陥る可能性があります。ハッシュ [sa_hash]: もう 1 つの問題は、Impact Calculator Jobs for Business Service です。ジョブがスタックしている場合は、sa_hashテーブルにも反映されます。sa_hashテーブルで見られる主な問題は、同期の失敗です。影響度ハッシュは他のハッシュと同期されません。コピージョブのハッシュ値とインパクトカリキュレーションジョブのハッシュがあります。ジョブの進捗状況の影響度計算はコピージョブの進捗状況に基づいているため、影響度ジョブのハッシュ値はコピージョブとほぼ同じです。問題は、コピージョブと影響ジョブの間のハッシュの値に大きなギャップ が見られる場合に発生します。これは、BS の影響ジョブがスタックしている場合に見られます。 sa_hashの一般的なケースのいくつかは次のとおりです。A. last_impact_bacth_copy_job値が低い。: コピージョブのハッシュが低く、影響度ジョブが高いことがわかるように、ここでは影響度計算ジョブは進行できません。 PRBを確認し、お客様が修正バージョンを使用しているかどうかを確認します。そうでない場合は、システムを安定させるために、次の手順に従います。 「last_impact_batch_copy_job」ハッシュ値を他のものと同じように変更します計算ハッシュの最高値)。上記の例では、224464以上に設定します。古いアラート履歴レコードのvt_endをvt_start値 [添付済み - emSupport-UpdateVTEndOfOldAlertHistoryRecordsToCurrent.txt] に更新しますすべてのオープンアラートをタッチ [添付済み - emSupport-TouchAllOpenAlerts.txt] [すべてのサービス] をタップします。このアクティビティでは、以下のステップを実行します。 インスタンスバージョン Washington より前 [attached -emSupport-TriggerServices.txt] の添付スクリプトを実行しますバージョンが Washington 以降の場合は、スケジュール済みジョブ「イベント管理 - 手動影響度算出トリガー」を実行してください B. last_impact_batch_calc_job-2は科学的な形をしている。: これは、アラートグループと SLA に影響します。ジョブは -2 で終了します。これは既知の問題PRB1564953 であり、すでに対処されています。 システムを安定させ、問題を解決するには、次の手順に従います。 「イベント管理 - アラートグループおよび SLA の影響度算出」ジョブを非アクティブ化します他のハッシュ値を同じ (コピー ジョブのハッシュ値よりも小さい値) に変更します。「イベント管理 - アラートグループと SLA の影響度算出」ジョブを再アクティブ化します C. calc ジョブハッシュ/バックフィルが同期していない。: これは、インパクトカリキュレーションジョブの 1 つが同期していない場合に発生します。これは理由の1つにすぎません。sa_hashが同期しなくなる理由は他にも考えられます。 PRBを確認し、お客様が修正バージョンを使用しているかどうかを確認します。そうでない場合は、システムを安定させるために、次の手順に従います。 「last_impact_batch_copy_job3」ハッシュ値を他の値と同じように変更します。上記の例では、314085以下に設定します。古いアラート履歴レコードのvt_endをvt_start値 [添付済み - emSupport-UpdateVTEndOfOldAlertHistoryRecordsToCurrent.txt] に更新しますすべてのオープンアラートをタッチ [添付済み - emSupport-TouchAllOpenAlerts.txt][すべてのサービス] をタップします。このアクティビティでは、以下のステップを実行します。 インスタンス Washington 以前のバージョン [attached -emSupport-TriggerServices.txt] に対して添付スクリプトを実行しますバージョン Washington 以降 の場合は、スケジュール済みジョブ「イベント管理 - 手動影響度算出トリガー」を実行してください D.ハッシュ名のエントリが重複しています: sa_hashテーブルに 同じハッシュ名を持つ複数のレコード が表示されることがあります。これを「ハッシュの重複問題」と呼んでいます。この場合は、以下の手順に従ってください。 特定の影響度ハッシュについては、最新更新/最終更新日のハッシュを見つけます更新された最新のハッシュを除き、重複するハッシュ値をすべて削除します。削除後、すべての Impact ハッシュが同期しているかどうかを確認します。そうでない場合は、KB の手順に従って、影響度ハッシュの同期の問題を修正します。 プロアクティブな対策として、セルフヘルスモニタリングを有効にすることができます。この動作を監視し、動作を報告するアラートを発生させる セルフヘルスモニタリング>>重複影響ハッシュ 監視 スクリプトがあります。 プラットフォームレベルでは、ハッシュの重複のリスクを知らせるソリューションを開発して、重複ハッシュの問題を防止し、回避できるようにしています。 2.サービスグループジョブが大量のメモリを消費する この問題は主に、Default Service Group[cmdb_ci_service_group] の「All」が原因で発生します。多くのサービスがあり、すべてがこのすべてのサービスグループの一部である場合、計算により多くのメモリが必要になり、インスタンスのパフォーマンスに影響します。東京では、このためにいくつかのパフォーマンスを改善しました。 この問題に対処するには、修正プログラムを別のバージョンに手動でバックポートする必要があります。添付スクリプト「EvtMgmtCalculateImpactForGroups」をインポートしてください。 注:顧客が Tokyo にアップグレードしたら、スクリプトを元に戻します。 3.大きい影響度グラフと影響度ステータステーブル 考えられる原因と解決策: 非常に大規模なサービス (推奨されるデフォルトの最大 CI 数を超えている)ダイナミック CI グループの場合、デフォルト値は「sa.qbs.max_num_of_cis」=10000 です多くのサービスが再構築されます CI の変更が影響を受ける可能性がある ダイナミック CI グループ フィルター -> 再構築 -> 影響度グラフの拡大 -> 影響度ステータスの拡大これを修正するには、動的 CI グループのフィルターを変更して、サービスの変更に対する感度を低くして、再構築の数を減らすことを検討してください。ネットワークストレージパスが関与している可能性があります:これを修正するには、以下のプロパティを設定して、アプリケーションサービスからネットワークパスを除外し、ダイナミック CI グループから VM を除外することを検討してください。 「evt_mgmt.network_path_excluded」を true に設定します 「evt_mgmt.enrich_topology_dynamic_cis」を false に設定します 頻繁な変更を伴うその他の再構築これを修正するには - CI 除外:KB0952256:サービスの再計算:特定の CI タイプを再計算から除外して、パフォーマンスの問題を軽減します svc_baseline_exclusion のフィールドごとの CI 変更の除外リスト クリーンアップジョブの問題:頻繁に正常に動作するクリーンアップジョブを確認し、データが削除されているかどうかを検証します。また、影響度関連のデータが非常に高い場合は、(イベント管理プロパティの下の) クリーンアッププロパティを 3 か月未満 (ただし 1 日以上) に変更することを検討してください 4.遅いクエリ インパクトカリキュレーション中にクエリーが遅くなるなどのパフォーマンスの課題が見つかった場合は、以下を確認できます。 アクティブなトランザクション – 通常よりも長く実行される特定の Impact ジョブはありますか?同じバケット ID を持つ大規模なサービスを探すクエリを検索し、ここで新しいインデックスを追加できるかどうかを検証します。V「大きな影響度グラフと影響度ステータステーブル 」セクションで説明されているクリーンアップジョブのプロパティに従って、影響度テーブルのサイズを検証し、サイズを制御します。 5.無効なカスタマイズ ビジネス要件の一環として、エンドユーザーがスケジュール済みジョブの [実行方法] を変更し、他のドメインでの実行を許可しないことがあります。 場合によっては、エンドユーザーが運用ステータスフィールドの値をカスタマイズして、サービスがアラートの影響を受けるサービスの下に表示されないことがあります。影響度計算ログエラーを確認しました:事前定義された「すべて」グループが見つかりませんでした。これは、サービスグループテーブルにレコード「すべて」が含まれていなかったためです (サービスグループの責任テーブルは「すべて」レコードに影響を与えました) トラブルシューティングフロー 以下のフローチャートは、トラブルシューティングのフローを説明しています。 参照 アラート影響度計算