依存アラート マッピングの有効化

機能の可用性： 依存アラート マッピングは、LogicMonitor Enterprise のユーザーが利用できます。

概要

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

アラート操作に対して依存アラート マッピングを有効にすると、インシデントの原因が強調表示され、必要に応じて、元のアラートに依存していると判断されたアラートの通知ルーティングが抑制されます。これにより、親リソースがダウンしたりアクセスできなくなったりして、依存するリソースもアラート状態になるイベントのアラート ノイズを大幅に減らすことができます。

依存アラート マッピングの仕組み

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

依存アラート マッピングを有効にすると、次のプロセスを通じてこの問題に対処できます。

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

依存アラート マッピングの要件

依存アラート マッピングを実行するには、次の要件を満たす必要があります。

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

依存アラート パッピングをトリガーするには、次のデータポイントで発生する重大度レベルのアラートによって判断されるように、リソースが到達不能またはダウンしている必要があります。

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

トポロジの前提条件

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

パフォーマンスの制限

依存アラート マッピングには次のパフォーマンス制限があります。

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

依存アラートマッピングの構成

作成する依存アラート マッピング構成のすべてのセットは、1 つ以上のエントリ ポイントに関連付けられます。で詳しく説明したように、 依存関係チェーンのエントリポイント このサポート記事のセクションでは、エントリ ポイントは依存関係チェーンが開始するリソース (つまり、結果として得られる依存関係チェーン階層の最高レベルのリソース) です。エントリポイント リソースに接続されているすべてのリソースは依存関係チェーンの一部となるため、依存関係チェーンの上流または下流のデバイスが到達不能になった場合、依存アラート マッピングの対象となります。

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

依存アラート マッピングを設定するには、次を選択します。 [設定] > [アラート設定] > [依存アラート マッピング] | > 追加。 さまざまな設定を構成できるダイアログが表示されます。 次に、各設定について説明します。

名前

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

優先

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

説明

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

エントリーポイント

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

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

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

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

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

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

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

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

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

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

エントリ ポイント リソースを選択すると、接続されたすべてのリソースがエントリ ポイントに依存するだけでなく、エントリ ポイントよりも近い他の接続されたリソースにも依存する依存関係階層が確立されます。これは、依存アラート マッピングのトリガーは、エントリ ポイントが到達不能になってアラートになることだけに依存していないことを意味します。依存関係チェーン内のノードが到達不能でアラート状態になると (PingLossPercent または idleInterval データポイントによって決定されます)、依存アラート マッピングがトリガーされます。

この依存関係チェーンの例では、ノード 1 がエントリ ポイントで、ノード 2 ～ 8 はすべてノード 1 に依存しています。ただし、他の依存関係も同様に存在します。たとえば、ノード 2 がダウンし、その結果ノード 4、6、および 7 が到達不能になった場合、RCA はノード 2 をノード XNUMX であるとみなします。 元来の ノード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 インターフェイスに通常どおり表示されます。次のセクションで説明するように、[アラート] ページには、依存アラート マッピングが行われるアラートの追加情報と表示オプションが表示されます。

依存アラート マッピングに固有の列とフィルター

[アラート] ページには、依存アラート マッピング機能に固有の 3 つの列と 2 つのフィルターが用意されています。

ルーティング状態列

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

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

依存関係の役割の列

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

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

依存アラート列

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

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

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

[依存関係]タブ

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

依存アラート マッピングに固有のアラートの詳細

依存アラート マッピング インシデントの一部であるアラートのアラート詳細には、根本原因に関連する追加の詳細が含まれます。これらの詳細は、LogicMonitor UI とアラート通知 (ルーティングされた場合) の両方に表示されます。

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

依存アラート マッピングの詳細はトークンとしても利用できます。カスタム アラート通知メッセージでのトークンの使用の詳細については、次を参照してください。 LogicModuleアラートメッセージで使用可能なトークン.

• ## DEPENDENCYMESSAGE ##

  発生したアラートに伴うすべての依存関係の詳細を表します。 依存アラートマッピング

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

監査ログによってキャプチャされた依存アラート マッピングの詳細

依存アラート マッピング構成を保存してから約 5 分後、「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 プラットフォームの他の多くの機能と同様、依存アラート マッピングはロールベースのアクセス制御をサポートします。デフォルトでは、デフォルトの管理者またはマネージャーの役​​割が割り当てられているユーザーのみが、依存アラート マッピング構成を表示または管理できます。ただし、で説明したように、 役割、ロールを作成または更新して、これらの構成にアクセスできるようにすることができます。