根本原因分析の有効化

機能の可用性： LogicMonitor Enterpriseのユーザーは、根本原因分析を利用できます。

概要

根本原因分析（RCA）は、LogicMonitorのトポロジマッピングAIOps機能によって検出された、監視対象リソース間の自動検出された関係を利用して、依存リソースに影響を与えているインシデントの根本原因を特定します。

アラート操作を有効にすると、根本原因分析によってインシデントの発生原因が強調表示され、オプションで、発生アラートに依存していると判断されたアラートの通知ルーティングが抑制されます。 これにより、親リソースがダウンしたり到達不能になったりしたイベントのアラートノイズを大幅に減らすことができるため、依存リソースもアラートになります。

根本原因分析のしくみ

アラートストーム中に、同じ発生インシデントに関連する多くのアラートがLogicMonitorで発生し、超過した各メトリックしきい値のアラートルール設定に基づいて多数の通知が送信される場合があります。 これにより、インシデントの根本原因がどのリソースであるかを明確に示すことなく、インシデントの影響を受けるリソースの通知が殺到する可能性があります。

根本原因分析を有効にすると、次のプロセスを通じてこの問題に対処できます。

1. 依存関係チェーン内のリソースの到達不能アラートを識別します。 根本原因分析は、トポロジの関係に基づいています。 識別された依存関係チェーンの一部であるリソースがダウンするか、到達不能になると、そのアラートに根本原因分析のフラグが立てられます。 リソースは、PingおよびHostStatusデータソースにそれぞれ関連付けられているPingLossPercentまたはidleIntervalデータポイントによって重大度レベルのアラートが発生した場合、ダウンしているか到達不能であると見なされます。
2. アラート通知のルーティングの遅延（オプション）。 依存関係チェーン内のリソースがダウンするか到達不能になると、この最初の「到達可能性」アラートにより、チェーン内のすべてのリソースが遅延通知状態になります。 この状態は、アラート通知の即時ルーティングを防ぎ、インシデントが完全に顕在化するための時間と、根本原因分析アルゴリズムが根本（つまり、発生元）および依存する原因を判別するための時間を提供します。
3. 依存関係の役割のメタデータをアラートに追加します。 到達可能性アラートのある依存関係チェーン内のリソースは、依存する子または抑制されたノードの親ノードまたは抑制ノードとして識別されます。 このプロセスは、アラートの依存関係の役割を発信元または依存関係として識別するメタデータをアラートに追加します。 このロールは、依存アラート通知を抑制するために必要なデータを提供します。
4. アラート通知のルーティングの抑制（オプション）。 依存していると識別されたアラートはルーティングされないため、アラートノイズは根本原因を識別したアラートだけに減少します。 （依存アラートは引き続きLogicMonitorインターフェイスに表示されます。通知ルーティングのみが抑制されます。）
5. 依存関係チェーン全体のアラートのクリア。 元の到達可能性アラートがクリアされ始めると、依存関係チェーン内のすべてのリソースが再び遅延通知状態になり、インシデント全体がクリアされるまでの時間が確保されます。 XNUMX分後、残りのアラートは通知のためにルーティングされます。それでも一部のリソースに到達できない場合は、これらのデバイスに対して新しい根本原因分析インシデントが開始され、プロセスが繰り返されます。

根本原因分析の要件

根本原因分析を実行するには、次の要件を満たす必要があります。

到達不能またはダウンリソース

根本原因分析をトリガーするには、次のデータポイントで重大度レベルが上昇しているというアラートによって決定されるように、リソースが到達不能またはダウンしている必要があります。

• PingLossPercent（Pingデータソースに関連付けられています）
• idleInterval（HostStatus DataSourceに関連付けられています）

トポロジの前提条件

根本原因分析は、監視対象のリソース間の関係に依存しています。 これらの関係は、LogicMonitorのトポロジマッピング機能を介して自動的に検出されます。 この機能が有効で最新であることを確認するには、を参照してください。 トポロジマッピングの概要.

パフォーマンスの制限

根本原因分析には、次のパフォーマンス制限があります。

• 依存ノードのデフォルト数（合計）：10,000デバイス
• RCA に使用されるトポロジ接続: ネットワーク、コンピューティング、ルーティング。
• トポロジデバイスERT（predef.externalResourceType）は、VirtualInstances、AccessPoints、およびUnknownを除外します。

根本原因分析の構成

作成する根本原因分析構成のすべてのセットは、XNUMXつ以上のエントリポイントに関連付けられています。 で詳細に説明されているように 依存関係チェーンのエントリポイント このサポート記事のセクションでは、エントリポイントは、依存関係チェーンが開始するリソース（つまり、結果の依存関係チェーン階層の最上位のリソース）です。 エントリポイントリソースに接続されているすべてのリソースは依存関係チェーンの一部になるため、依存関係チェーンのアップストリームまたはダウンストリームのデバイスが到達不能になった場合、根本原因分析の対象になります。

エントリポイントごとに異なる設定を構成する機能により、かなりの柔軟性が得られます。 たとえば、MSPには、通​​知の遅延を許可するクライアントと、厳密なSLAが原因ではないクライアントがあります。 または、企業は、一部のリソースに依存するアラートをルーティングしたいが、他のリソースにはルーティングしたくない場合があります。

根本原因分析を構成するには、 設定| アラート設定| 根本原因分析| 追加。 さまざまな設定を構成できるダイアログが表示されます。 次に、各設定について説明します。

お名前

お名前 フィールドに、構成のわかりやすい名前を入力します。

優先

優先 フィールドに、数値の優先度値を入力します。 「1」の値は、最高の優先度を表します。 同じリソースに複数の構成が存在する場合、このフィールドにより、最も優先度の高い構成が使用されます。 エントリポイントの選択が一意のリソースを表すようにすることに熱心に取り組んでいる場合は、優先順位が関係することはありません。 このフィールドの値は、エントリポイントのカバレッジが別の構成で重複している場合にのみ使用されます。

説明

説明 フィールドに、オプションで構成の説明を入力します。

エントリーポイント

[トポロジベースの依存関係のエントリポイントの選択]構成領域で、プラス記号（+）アイコンをクリックして、この構成のエントリポイントとして機能するXNUMXつ以上のグループや個々のリソースを追加します。 どちらの場合も グループ or リソース フィールドにワイルドカード（*）を入力して、すべてのグループまたはすべてのリソースを示すことができます。 エントリポイント構成ごとにワイルドカードを含めることができるのは、これらのフィールドのXNUMXつだけです。 たとえば、リソースグループを選択してもリソースをワイルドカードのままにすると、選択したグループ内のすべてのリソースがエントリポイントとして返されます。

エントリポイントリソースの選択では、このリソースのトポロジ関係を使用して、根本原因分析が有効になっている親/子の依存関係階層（つまり依存関係チェーン）を確立します。 この依存関係チェーン内のいずれかのリソースがダウンすると、依存関係チェーンのメンバーから発生するすべてのアラートの根本原因分析がトリガーされます。

保存されると、エントリポイントへのすべての依存ノード、およびエントリポイントからの分離度が、で説明されているように監査ログに記録されます。 監査ログによってキャプチャされた根本原因の詳細 このサポート記事のセクション。

エントリポイントを選択するためのガイドライン

可能であれば、エントリポイントとしてコレクタホストを選択する必要があります。 監視が開始される場所として、それは最も正確なエントリポイントです。 ただし、コレクターホストが監視中でない場合、またはネットワークデバイスへのパスがトポロジマッピングを介して検出されない場合は、コレクターホストに最も近いデバイス（つまり、コレクターアクセス用のネットワークへのプロキシまたはゲートウェイとして機能するデバイス）選択する必要があります。

通常の環境では、コレクターごとにXNUMXつのエントリポイントを作成する必要があります。 次の図は、これらのエントリポイントを選択するためのガイドラインを示しています。

コレクターホストが監視され、ネットワークデバイスへのパスがトポロジを介して検出可能である場合、それがネットワークの内部（上の例に示されている）または外部（下の例に示されている）にあるかどうかに関係なく、エントリポイントである必要があります。

コレクターホストが監視されていない場合、コレクターホストに最も近いデバイス、通常はホストがネットワーク内にある場合はスイッチ/ルーター（上の例に示されています）、またはホストがネットワーク外にある場合はファイアウォール（下の例に示されています） ）、エントリポイントとして選択する必要があります。

コレクタホストが監視されているが、ネットワークデバイスへのパスがトポロジを介して検出できない場合は、監視と検出の両方が行われるコレクタホストに最も近いデバイスをエントリポイントとして選択する必要があります。

結果として生じる依存関係の連鎖を理解する

エントリポイントリソースを選択すると、接続されているすべてのリソースがエントリポイントだけでなく、エントリポイントよりも近い他の接続されているリソースにも依存する依存関係階層が確立されます。 これは、根本原因分析のトリガーが、エントリポイントが到達不能になり、アラートが発生することだけに依存していないことを意味します。 到達不能でアラートが発生する依存関係チェーン内のノード（PingLossPercentまたはidleIntervalデータポイントによって決定される）は、根本原因分析をトリガーします。

この依存関係チェーンの例では、ノード1がエントリポイントであり、ノード2〜8はすべてノード1に依存しています。ただし、他の依存関係も存在します。 たとえば、ノード2がダウンし、その結果、ノード4、6、および7が到達不能になった場合、根本原因分析ではノード2が 元来の ノード4、6、および7でのアラートの原因。ノード2も 直接 ノード4でのアラートの原因。ノード4は 直接 ノード6および7でのアラートの原因。 根本原因分析に固有のアラートの詳細 このサポート記事のセクションでは、依存していると見なされるすべてのアラートについて、発信元および直接の原因のリソースが表示されます。

依存通知を無効にする

次のオプションを使用して、根本原因分析インシデント中に依存アラートの通知ルーティングを抑制します。

• 依存する「到達可能性」アラートの通知を無効にします（Ping-PingLossPercentおよびHostStatus-IdleInterval）。 このオプションをオンにすると、PingLossPercent（Ping DataSourceに関連付けられている）またはidleInterval（HostStatus DataSourceに関連付けられている）データポイントのいずれかによってトリガーされる依存アラートのアラート通知が無効になります。
• 他のすべての依存アラート通知を無効にします。 このオプションをオンにすると、依存アラートのルーティングを無効にすることもできますが、これらの依存アラートがリソースのダウンまたは到達不能の結果である場合は無効になります（PingLossPercentまたはidleIntervalデータポイントによって決定されます）。 つまり、PingLossPercentまたはidleInterval以外のデータポイントによってトリガーされる依存アラートの通知は抑制されます。 PingLossPercentまたはidleIntervalによってトリガーされる依存アラートの通知は、ルーティング用にリリースされます。

ほとんどの場合、両方のオプションをチェックして、依存するすべてのアラートルーティングを抑制し、発生原因を表すと判断されたアラートのみを解放することをお勧めします。 ただし、より微妙な制御のために、到達可能性アラートのみ、または到達不可能性アラートのみを無効にすることができます。 これは、さまざまなチームがさまざまな種類のアラートに対処する責任がある場合に役立つことがあります。

ルーティング遅延

デフォルトでは、 アラートルーティング遅延を有効にする オプションがチェックされています。 これにより、アラートが根本原因分析をトリガーしたときに、依存関係チェーンの一部であるすべてのリソースのアラート通知ルーティングが遅延し、インシデントが完全に顕在化し、アルゴリズムが元の原因と依存アラートを判別するための時間が確保されます。 で説明されているように 依存アラートの表示 このサポート記事のセクションでは、根本原因の状態が評価されている間、アラートのルーティング段階で「遅延」が示されます。

ルーティング遅延が有効になっている場合、 最大アラートルーティング遅延時間 フィールドが利用可能です。 このフィールドは、根本原因分析のためにアラートルーティングを遅延できる最大時間を決定します。

最大制限時間に達しても評価がまだ行われている場合（または アラートルーティング遅延を有効にする オプションがオフになっている場合）、通知は、その時点で利用可能な根本原因データを使用してルーティングされます。 遅延が許可されていない場合、これは、根本原因データが通知に含まれないことを意味する可能性があります。 ただし、どちらの場合も、インシデントが顕在化すると、アラートは進化し続け、アラートに追加情報が追加され、依存していると判断されたアラートの場合は、追加のエスカレーションチェーンステージが抑制されます。

依存アラートの表示

根本原因分析が行われるアラートは、依存アラートとして識別された結果として通知が抑制されたアラートでも、通常どおりLogicMonitorインターフェイスに表示されます。 次のセクションで説明するように、[アラート]ページには、根本原因分析を受けるアラートの追加情報と表示オプションが表示されます。

根本原因分析に固有の列とフィルター

[アラート]ページには、根本原因分析機能に固有のXNUMXつの列とXNUMXつのフィルターがあります。

ルーティング状態列

[ルーティング状態]列には、アラート通知の現在の状態が表示されます。 XNUMXつの可能なルーティング状態があります。

• 遅延。 「遅延」ルーティング状態は、アラートの依存関係の役割がまだ評価中であり、したがって、アラートがルーティング通知用にリリースされていないことを示します。
• 抑制。 「抑制された」ルーティング状態は、アラートが依存していると判断され、根本原因分析構成に設定された通知無効化基準を満たしているため、アラートの後続のアラート通知がルーティングされなかったことを示します。
• ノーマル。 「通常の」ルーティング状態は、アラートルールで指定されている標準ルーティングに対してアラート通知がリリースされたことを示します。

依存関係の役割の列

[依存関係の役割]列には、インシデントでのアラートの役割が表示されます。 XNUMXつの可能な依存関係の役割があります。

• 未定。 「TBD」依存関係の役割は、インシデントがまだ評価中であり、依存関係がまだ決定されていないことを示します。
• 発信。 「発信元」の依存関係の役割は、アラートがインシデントの根本原因（または根本原因のXNUMXつ）であるリソースを表していることを示します。
• 依存。 「依存」依存関係の役割は、アラートが別のアラートの結果であり、それ自体が根本原因を表していないことを示します。

依存アラート列

[依存アラート]列には、アラートに依存しているアラートの数が表示されます（存在する場合）。 アラートが発信アラートである場合、この数には、依存関係チェーン内のすべてのリソースからのすべてのアラートが含まれます。 アラートが発信元のアラートでない場合でも、依存関係チェーンの下流のリソースを表すアラートは現在のアラートに依存していると見なされるため、依存アラートが存在する可能性があります。

ルーティング状態と依存関係の役割フィルター

LogicMonitorは、[ルーティング状態]列と[依存関係の役割]列のデータに基づいてXNUMXつのフィルターを提供します。 これらのフィルターの基準は、各列で使用可能な値と一致します。

[依存関係]タブ

依存アラート（つまり、発生原因アラートまたは直接原因アラート）を含むアラートの詳細を表示する場合、[依存関係]タブが追加で使用できます。 このタブには、アラートのすべての依存アラート（つまり、依存チェーンの下流にあるリソースのすべてのアラート）が一覧表示されます。 これらの依存アラートは、を使用して確認するか、スケジュールされたダウンタイム（SDT）にまとめて配置できます。 すべてを認める および SDTすべて ボタン。

根本原因分析に固有のアラートの詳細

根本原因分析インシデントの一部であるアラートのアラートの詳細には、根本原因に関連する追加の詳細が含まれます。これらの詳細は、LogicMonitor UIとアラート通知（ルーティングされている場合）の両方に表示されます。

アラートタイプ、アラートロール、および依存アラートカウントには、前のセクションで説明した列と同じ詳細が含まれます。 アラートが発信元アラートでない場合は、発信元の原因と直接の原因のリソース名も提供されます。 直接原因リソースは、特定のリソースが直接依存しているエントリポイントに一歩近い隣接リソースです。

根本原因の詳細は、トークンとしても入手できます。 カスタムアラート通知メッセージでのトークンの使用の詳細については、を参照してください。 LogicModuleアラートメッセージで使用可能なトークン.

• ## DEPENDENCYMESSAGE ##

  根本原因分析を受けたアラートに付随するすべての依存関係の詳細を表します

• ## ALERTDEPENDENCYROLE ##
• ## DEPENDENTRESOURCECOUNT ##
• ## DEPENDENTALERTCOUNT ##
• ## ROUTINGSTATE ##
• ##発生原因##
• ## DIRECTCAUSE ##

監査ログによってキャプチャされた根本原因の詳細

根本原因分析構成を保存してから約XNUMX分後に、「System：AlertDependency」ユーザーのLogicMonitorの監査ログに次の情報が記録されます。

エントリポイント（type：name（id）：status：level：waitingStartTime）：

依存関係にあるノード（type：name（id）：status：level：waitingStartTime：EntryPoint）：

どこ：

• status （ノードまたはエントリポイントの）はNormal | WaitingCorrelation | Suppressing | Suppressed | WaitingClear
• レベル ノードがエントリポイントから削除されるステップ数です（エントリポイントの値は常に0です）。
• 待機開始時間 ノードが「WaitingCorrelation」のステータス状態にある場合の遅延の開始です

監査ログの使用の詳細については、を参照してください。 監査ログについて.

依存関係チェーンのモデリング

（前のセクションで説明したように）監査ログによってキャプチャされたエントリポイントと依存ノードの詳細を使用して、根本原因分析構成のエントリポイントと依存ノードを表すトポロジマップの構築を検討することをお勧めします。 トポロジマップはアラートステータスを視覚的に示すため、これはインシデントを一目で評価するときに非常に役立ちます。 トポロジマップの作成の詳細については、を参照してください。 マッピングページ.

ロールベースのアクセス制御

LogicMonitorプラットフォームの他の多くの機能と同様に、根本原因分析は役割ベースのアクセス制御をサポートします。 デフォルトでは、デフォルトの管理者またはマネージャーの役​​割が割り当てられているユーザーのみが、根本原因分析の構成を表示または管理できます。 ただし、 役割、ロールを作成または更新して、これらの構成にアクセスできるようにすることができます。