Event Management - Impact 計算の説明<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 目次 はじめにImpact CalculationとはImpact Calculation の仕組み 1.Alert テーブルから Alert History テーブルへのアラートデータのコピー2.コピーされたデータを Impact Calculation に使用する インパクトカリキュレーションの問題のトラブルシューティング 1.現在のアラートステータスがオペレーターワークスペースに反映されない2.サービスグループジョブが大量のメモリを消費する3.大きい影響度グラフと影響度ステータステーブル4.遅いクエリ5.無効なカスタマイズ トラブルシューティングフロー参照 はじめに この記事の目的は、TSE が Impact Calculation 機能とそのトラブルシューティングを理解できるようにすることです。 Impact Calculationとは Impact Calculation は、CI、Service、Alert、および Alert Group に対する機能停止の規模を表示します。そのため、機能停止が発生した場合に、ビジネス全体への影響をお客様が理解するうえで重要です。Impact Calculation は Event Management の一部であり、Service の現在の Status を確認するために使用されます。 Event Management ➔ Operator Workspace に移動します。 以下に例を示します。 ここでは、Normal の Service と影響を受けている Service を確認できます。影響を受けている Service を開くと、Service 全体に影響を与えている Node を明確に把握できます。 Impact Calculation の仕組み Impact Calculation は、Impact Rules や CI Relationships などの要素を使用して、生成された Alert の Severity を計算します。Severity は、Impact Tree、Application Service Maps、および Dashboard に表示されます。主に次の 2 つの手順があります。 Alert テーブルから Alert History テーブルに Alert データをコピーコピーされたデータを Impact Calculation に使用 1.Alert テーブルから Alert History テーブルへの Alert データのコピー Alert History [em_alert_history] OOTB には、Event Management - Impact Calculator Trigger という Scheduled Job があります。この Job は、Alert テーブルから Alert History テーブルにデータをコピーし、レコードの VT_end フィールドに値を設定します。Alert テーブルとは異なり、Alert History テーブルでは、同じ Alert 番号に対して複数のエントリが存在することが想定されています。例: Alert0010056。Alert が Insert または Update されるたびに、レコードが Alert History テーブルにコピーされます。最新のエントリでは、Alert Valid Time End に常に将来の日付が設定されます。そのため、State が Open で、将来の日付が設定されている Alert エントリがある場合、その Alert によって Active Impact が発生していることを意味します。基本的に、VT END は Alert の有効期間を示します。 上の画像は下から上に読んでください。 最初のレコードの Alert Valid Time Start は 2022-09-08 09:18:49、Alert Valid Time End は 2022-09-08 09:19:08 です。これは、スクリーンショットに示されている現在の Status です。ただし、このレコードがテーブル内の最初のレコードであった時点では、Impact の終了時刻が不明であったため、Alert Valid Time End は 8994-08-17 00:12:55 でした。これは、Alert の Impact が 2022-09-08 09:18:49 に開始され、どのくらいの期間継続するかが不明であることを意味します。そのため、Impact を Active の状態に維持するために、終了日に将来の日付を設定します。これは、現在から約 6977 年後の日付です。しばらくすると Alert レコードが更新され、Copy Job は更新された Alert のコピーを 2022-09-08 09:19:08 に Alert History テーブルにコピーします。これは下から 2 番目のレコードです。これは、以前の Alert のコピーが無効になったことを意味します。そのため、以前のレコード、つまり下から 1 番目のレコードの End Time を 2022-09-08 09:19:08 に設定します。同じ値が 2 番目のレコードの Start Time になり、この処理が継続されます。最上位のレコードを見ると、Start Time は 2022-09-08 09:19:08 です。このレコードがいつまで Active であるかは不明であるため、End Time を 8994-08-17 00:12:55 に設定します。将来の日付が設定されていても問題ありません。これは想定された動作です。この Alert History データは、特定の Service に対する CI の Impact を計算するために使用されます。Maintenance 状態ではない Alert の Impact が表示されます。Alert がすでに Maintenance 状態になっている場合、Impact は表示されません。Alert History テーブルのデータは 3 か月間保存され、30 分ごとに実行される Event Management - Clean Alert History Table Scheduled Job によって削除されます。vt_end が 8994 である Event は、その Event がまだ Active であることを示します。そのため、このような Event が削除されることは想定されていません。クリーンアップは vt_start の日付に基づいて実行されます。 注記: Operator Workspace 上の Service の Status には、Alert テーブルの Status ではなく、Alert History テーブルの Status 値が反映されます。 2.コピーされたデータを Impact Calculation に使用する Impact Calculation には 3 つの重要なテーブルがあります。 Impact Graph [em_impact_graph]Impact Status [em_impact_status]Hashes [sa_hash] Impact Graph [em_impact_graph] Impact Tree Builder Job、つまり Event Management - Impact Tree Builder は、em_impact_changes テーブル内で変更されたすべての Service を処理し、その Impact Tree を再構築します。この Job は 11 秒ごとに実行されます。Impact Tree の構築時に、レコードが em_impact_graph に挿入されます。この処理は Alert に依存せず、Service Mapping Topology および Impact Rules に基づいて構築されます。Impact Tree は、CI の親子関係に対する Impact Rules の結果を表示します。この Tree は、Service Configuration Item Associations [svc_ci_assoc] テーブルの CI を使用した Service Map を表します。 例えば、service_v1_40 の例を見ると、このレコードが Service レコードであり、2 つの CI が 1 つの Service レコードを参照していることが分かります。すべてのレコードの Status は Valid であり、Is service は true と表示されています。 システムが Service の再構築を試みた場合、または Service の Status を Operational から Non-Operational に変更し、その後 Operational に戻した場合、その Service に関連付けられているすべてのレコードが削除され、Status が Valid の新しいレコードが作成されます。 Impact Status [em_impact_status] Service Graph にデータが設定されると、Alert の Impact Calculation 用に 6 つの Job が使用されます。これらの Job は、em_alert_history および em_impact_graph に基づいて動作します。これらの Job は、em_impact_status テーブル内で Service の Severity を計算し、VT end フィールドを更新します。Job の詳細は次のとおりです。 Event Management - Impact Calculator for BS [Bucket 0-3] - Bucket 0～3 の Service の Impact を計算します。Event Management - Impact Calculator for BS [Bucket 2] - Alert Group および SLA 用です。Event Management - Impact For Service Group - Service Group に対する Impact を計算します。 これらの Job は Alert History レコードを使用し、em_impact_status にエントリを作成します。em_impact_status のデータはデフォルトで 3 か月間保存されます。このデータには、CI の Severity Status と、その CI が属する Service にどのような影響を与えるかが反映されます。このテーブルは、em_alert_history および em_impact_graph に基づいています。 Impact Calculation の問題のトラブルシューティング Impact Job で確認されている主なシナリオは、次の 5 つです。 現在の Alert Status が Operator Workspace に反映されないService Group Job が大量のメモリを消費するImpact Graph および Impact Status テーブルが大きいクエリが遅い無効なカスタマイズ 現在の Alert ステータスが Operator Workspace に反映されない Operator Workspace 上の Alert Status に不一致がある場合、まず次のテーブルを確認し、問題が発生している場所を特定する必要があります。 Alert History [em_alert_history]Alert Impact Status [em_impact_status]Hashes [sa_hash]A. Alert History [em_alert_history]Use Case 1: Alert データがコピーされていない Alert がテーブルにコピーされているかどうかを確認する必要があります。コピーされていない場合は、Event Management - Impact Calculator Trigger Copy Job に問題があることを意味します。Job の実行を検証し、エラーが報告されていないか確認するために、Application Node Logs および System Logs を確認してください。Alert History テーブルへのデータのコピーが開始されるように、Job を修正する必要があります。 Use Case 2: Alert データはコピーされるが正しくない Alert はコピーされても、レコードの正しい Status がコピーされないことがあります。これは、処理が遅い Business Rule により、Copy Job の実行前にデータが DB にコミットされていない場合に発生する可能性があります。処理が遅いカスタム Business Rule によって Alert レコードの更新が遅延するケースに対処するには、次の項目を確認します。 evt_mgmt.max_objs_in_alert_query:このプロパティの値が 500 ではなく、常に 1 に設定されていることを確認してください。OOTB では、この値は 1 に設定されています。500 に設定すると、トランザクション内の 500 件の Event がすべて処理されるまで、DB に何もコミットされません。そのため、処理が遅延します。処理がより早く完了するように、Event を 1 件ずつ処理することをお勧めします。 evt_mgmt.impact_calculation.alert_copy_delay:デフォルトでは、このプロパティの値は 2 ミリ秒に設定されています。このプロパティは OOTB では表示されません。Job の実行中に、すべての Alert テーブルで処理が遅い Business Rule が実行されていないか確認する必要があります。処理が遅い Business Rule が実行されている場合は、evt_mgmt.impact_calculation.alert_copy_delay の値を大きくすることを検討してください。デフォルト値は 2 ミリ秒です。これにより、Job は [now - n] より前に更新されたレコードを対象とします。n はこのプロパティの値を表します。注記: 上記の変更後、新しいレコードには変更が適用されますが、既存のレコードは引き続き不整合な状態になります。既存のデータに対処するには、KB0826649 の手順 3 に従うか、KA に添付されている emSupport-touchOpenAlertsHistory.txt スクリプトを実行してください。 もう 1 つの問題として、VT END の日付が正しくない場合があります。Copy Job がこの値を更新することは確認されています。ただし、Backfill に問題がある場合、このフィールドは更新されません。これは、sa_hash テーブル上の Backfill Hash 値に同期ずれがあることが原因である可能性があります。 B. Alert Impact Status [em_impact_status] Impact Status がユーザーの期待している状態を反映していない場合は、Impact Graph テーブルのレコードを確認し、その CI が Service に含まれているかどうかを確認します。詳細は前述のとおりです。さらに、問題を検証するために、Impact Status テーブルに対して次の基本的な確認を行うことをお勧めします。 Compare VT Dates: 報告されている影響対象の Service について、VT Start と VT End が正しく設定されていることを確認してください。上のスクリーンショットの最初のレコードを見ると、CI ci_v1_179_1_1 が Element Identifier として service_v1_179 Business Service を参照しています。Impact は 2022-09-05 23:13:44 に開始し、8994-08-17 00:12:55 まで継続します。一方、2 番目のレコードを見ると、同じ CI に対する Impact は 2022-09-05 23:13:37 に開始し、2022-09-05 23:13:44 に終了しています。したがって、1 番目と 2 番目のレコードを比較すると、2 番目のレコードは Impact が 2022-09-05 23:13:44 に終了したことを示していますが、1 番目のレコードの Impact はまだ Active です。上のスクリーンショットは正常な動作例です。この動作に不一致がある場合は、Impact Calculation に問題があります。 この場合、基本的なトラブルシューティングとして、Service を Operational から Non-Operational に変更し、その後 Operational に戻すことができます。これにより、既存の Impact Graph がすべて削除され、新しい Impact Graph が構築されます。その後、新しく構築されたエントリが計算に使用されます。注記: 上記の手順は、根本原因を特定した後にのみ実行してください。根本原因を特定せずに Service Operational Status を変更した場合、将来的に同じ問題が再発する可能性があります。 C. Hashes [sa_hash] もう 1 つの問題として、Business Service 用の Impact Calculator Job に問題がある場合があります。Job が停止している場合、その状態は sa_hash テーブルにも反映されます。sa_hash テーブルで確認される主な問題は同期ずれです。Impact Hash が他の Hash と同期していません。Copy Job 用の Hash 値と、Impact Calculation Job 用の Hash 値があります。Impact Calculation Job の進行状況は Copy Job の進行状況に基づいているため、Impact Job の Hash 値は Copy Job の Hash 値とほぼ同じになります。 Copy Job と Impact Job の Hash 値に大きな差がある場合に、問題が発生します。これは、Business Service 用の Impact Job が停止している場合に確認されます。 sa_hash で確認される一般的なケースは次のとおりです。 a. last_impact_bacth_copy_job値が低い Copy Job の Hash 値が低く、Impact Job の Hash 値が高い場合、Impact Calculation Job は処理を進めることができません。 PRB を確認し、お客様が修正済みバージョンを使用しているかどうかを確認してください。修正済みバージョンを使用していない場合は、システムを安定させるために、次の手順を実行できます。 last_impact_batch_copy_job の Hash 値を、他の値、つまり最も高い calc Hash 値と同じ値に変更します。上の例では、224464 以上に設定します。古い Alert History レコードの vt_end を vt_start の値に更新します。[添付ファイル - emSupport-UpdateVTEndOfOldAlertHistoryRecordsToCurrent.txt]すべての Open Alert を Touch します。[添付ファイル - emSupport-TouchAllOpenAlerts.txt] すべての Service を Touch します。この作業では、次の手順を実行します。 Washington より前のバージョンの Instance では、添付されている emSupport-TriggerServices.txt] スクリプトを実行します。Washington 以降のバージョンでは、Event Management - Manual Impact Calculator Trigger Scheduled Job を実行します。 b. last_impact_batch_calc_job-2 が Scientific Form になっている これは Alert Group および SLA に影響します。この Job 名は -2 で終わります。これは既知の問題 PRB1564953 であり、すでに対処されています。 システムを安定させて問題を修正するには、次の手順を実行します。 Event Management - Impact Calculator for Alert Groups and SLA Job を無効にします。対象の Hash 値を他の Hash 値と同様の値に変更します。この値は、Copy Job の Hash 値より小さい値にします。Event Management - Impact Calculator for Alert Groups and SLA Job を再度有効にします。 c. calc Job Hash／Backfill の同期ずれ これは、Impact Calculation Job のいずれかに同期ずれがある場合に発生します。ただし、これは原因の 1 つにすぎません。sa_hash に同期ずれが発生する原因は、ほかにもあります。 PRB を確認し、お客様が修正済みバージョンを使用しているかどうかを確認してください。修正済みバージョンを使用していない場合は、システムを安定させるために、次の手順を実行できます。 last_impact_batch_copy_job3 の Hash 値を、他の値と同じ値に変更します。上の例では、314085 以下に設定します。古い Alert History レコードの vt_end を vt_start の値に更新します。[添付ファイル - emSupport-UpdateVTEndOfOldAlertHistoryRecordsToCurrent.txt]すべての Open Alert を Touch します。[添付ファイル - emSupport-TouchAllOpenAlerts.txt] すべての Service を Touch します。この作業では、次の手順を実行します。 Washington より前のバージョンの Instance では、添付されているemSupport-TriggerServices.txt スクリプトを実行します。Washington 以降のバージョンでは、Event Management - Manual Impact Calculator Trigger Scheduled Job を実行します。 D.ハッシュ名のエントリが重複している sa_hash テーブルに、同じ Hash 名を持つ複数のレコードが存在することがあります。これを duplicate hash issue と呼びます。 対象の Impact Hash について、最新の更新日時を持つ Hash を特定します。最新の Hash を除き、重複しているすべての Hash 値を削除します。削除後、すべての Impact Hash が同期していることを確認します。同期していない場合は、Impact Hash の同期問題を修正するための KB の手順に従います。 予防策として、Self Health Monitoring を有効にできます。プロアクティブな対策として、セルフヘルスモニタリングを有効にすることができます。Self-health Monitoring >> Duplicate Impact Hashes Monitor スクリプトは、この動作を監視し、該当する動作を報告する Alert を生成します。Platform レベルでは、重複する Hash のリスクを把握できる Solution の開発に取り組んでいます。これにより、duplicate hash issue を未然に防止できるようになります。 2.サービスグループジョブが大量のメモリを消費する この問題は、主にデフォルトの Service Group [cmdb_ci_service_group] の All で確認されます。多数の Service があり、それらすべてが All Service Group に含まれている場合、計算に大量のメモリが必要になり、Instance のパフォーマンスに影響します。この問題に対応するため、Tokyo でいくつかのパフォーマンス改善が行われました。この問題に対処するには、修正を別のバージョンに手動で Backport する必要があります。添付されている EvtMgmtCalculateImpactForGroups スクリプトをインポートしてください。 注記: お客様が Tokyo に Upgrade した後は、このスクリプトを元に戻してください。 3. Impact Graph および Impact Status テーブルが大きい 考えられる原因と解決策は次のとおりです。 非常に大規模なサービス (推奨されるデフォルトの最大 CI 数を超えている)Service が推奨されるデフォルトの最大 CI 数を超えている可能性があります。ダイナミック CI グループの場合、デフォルト値は「sa.qbs.max_num_of_cis」=10000 です。Service が何度も再構築される CI の変更が Dynamic CI Group の Filter に影響する場合があります。CI Changes → Rebuild → Impact Graph が増加 → Impact Status が増加 この問題を修正するには、Dynamic CI Group の Filter を Service の変更に対する感度が低くなるように変更し、再構築の回数を減らすことを検討してください。 Network Storage Path が関係している可能性がある この問題を修正するには、次のプロパティを設定し、Network Path を Application Service から除外し、VM を Dynamic CI Group から除外することを検討してください。 evt_mgmt.network_path_excluded = trueevt_mgmt.enrich_topology_dynamic_cis = false svc_baseline_exclusion のフィールドごとの CI 変更の除外リスト クリーンアップジョブの問題: クリーンアップ Job が正常かつ定期的に動作していることを確認し、データが削除されているかどうかを検証します。Impact 関連のデータ量が非常に多い場合は、Event Management Properties にあるクリーンアッププロパティを、デフォルトの 3 か月より短い期間に変更することを検討してください。ただし、1 日以上に設定してください。 4. クエリが遅い Impact Calculation 中に Query が遅くなるなどのパフォーマンス上の問題が確認された場合は、次の項目を確認します。 Active Transactions を確認します。通常より長時間実行されている特定の Impact Job があるか確認してください。同じ Bucket ID を持つ大規模な Service を探します。Query を特定し、新しい Index を追加できるかどうかを検証します。Impact テーブルのサイズを確認します。Impact Graph および Impact Status テーブルが大きいセクションで説明したクリーンアップ Job のプロパティを使用して、サイズを管理します。 5.無効なカスタマイズ Business 要件の一環として、エンドユーザーが Scheduled Job の Run as を変更することがあります。これにより、その Job をほかの Domain で実行できなくなります。 エンドユーザーが Operational Status フィールドの値をカスタマイズする場合があります。このカスタマイズにより、Service が Alert の Impacted Services に表示されなくなることがあります。次の Impact Calculation ログエラーが確認されています。 Predefined 'All' group was not found.これは、Service Groups テーブルに All レコードが存在しなかったことが原因です。Service Group Responsibilities テーブルが All レコードに影響していました。 トラブルシューティングフロー 以下のフローチャートは、トラブルシューティングのフローを示しています。 参照 アラート影響度計算