依存アラートマッピング

最終更新日: 14 年 2024 月 XNUMX 日

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

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

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

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

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

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

  1. 依存関係チェーン内のリソースの到達不能アラートを識別します。 依存アラート マッピングはトポロジ関係に基づいています。特定された依存関係チェーンの一部であるリソースがダウンするか、到達不能になると、そのアラートには依存アラート マッピングのフラグが立てられます。リソースは、それぞれ Ping および HostStatus データソースに関連付けられている PingLossPercent または idleInterval データポイントによって何らかの重大度レベルのアラートが生成された場合、ダウンまたは到達不能とみなされます。
  2. アラート通知のルーティングの遅延(オプション)。 依存関係チェーン内のリソースがダウンするか、到達不能になると、この最初の「到達可能性」アラートによって、チェーン内のすべてのリソースが遅延通知状態になります。この状態では、アラート通知の即時ルーティングが妨げられ、インシデントが完全に顕在化し、依存アラート マッピング アルゴリズムが元の原因と依存原因を特定する時間が確保されます。
  3. 依存関係の役割のメタデータをアラートに追加します。 到達可能性アラートのある依存関係チェーン内のリソースは、依存する子または抑制されたノードの親ノードまたは抑制ノードとして識別されます。 このプロセスは、アラートの依存関係の役割を発信元または依存関係として識別するメタデータをアラートに追加します。 このロールは、依存アラート通知を抑制するために必要なデータを提供します。
  4. アラート通知のルーティングの抑制(オプション). Those alerts identified as dependent are not routed, thus reducing alert noise to just those alerts that identify the root cause. (Dependent alerts still display in the LogicMonitor interface; only notification routing is suppressed.)
  5. Clearing of alerts across the dependency chain. 元の到達可能性アラートがクリアされ始めると、インシデント全体がクリアされるまでの時間を確保するために、依存関係チェーン内のすべてのリソースが再び遅延通知状態になります。 5 分後、残りのアラートは通知のためにルーティングされます。または、一部のリソースがまだ到達できない場合は、これらのデバイスに対して新しい依存アラート マッピング インシデントが開始され、プロセスが繰り返されます。

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

For Dependent Alert Mapping to take place, the following requirements must be met.

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

To trigger Dependent Alert Mapping, a resource must be unreachable or down, as determined by an alert of any severity level being raised on the following datapoints:

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

注: 依存アラート マッピングは現在リソースに限定されており、インスタンスには拡張されません。たとえば、他のデバイスが接続に依存しているインターフェイスがダウンしている場合、依存アラート マッピングはトリガーされません。

トポロジの前提条件

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

パフォーマンスの制限

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

  • 依存ノードのデフォルト数(合計):10,000デバイス
  • Topology Connections used for Dependent Alert Mapping: Network/NETWORK, Compute/COMPUTE, BGP Peer, and OSPF Peer.
  • トポロジデバイスERT(predef.externalResourceType)は、VirtualInstances、AccessPoints、およびUnknownを除外します。

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

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

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

依存アラート マッピングを設定するには、次の場所に移動します。 設定 > 警告 > 依存アラートマッピング をクリックして Add Dependent Alert Mapping アイコンを追加. さまざまな設定を構成できるダイアログが表示されます。

お名前

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

優先

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

説明

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

エントリーポイント

 トポロジ ベースの依存関係のエントリ ポイントの選択 設定で、この構成のエントリ ポイントとして機能する XNUMX つ以上のグループまたは個々のリソースを指定します。 どちらかのために グループ or リソース フィールドにワイルドカード (*) を入力して、すべてのグループまたはすべてのリソースを示すことができます。 これらのフィールドのうち、エントリ ポイントの構成ごとにワイルドカードを含めることができるのは XNUMX つのみです。 たとえば、リソース グループを選択してリソースをワイルドカードのままにすると、選択したグループ内のすべてのリソースがエントリ ポイントとして返されます。

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

保存されると、エントリポイントへのすべての依存ノード、およびエントリポイントからの分離度が、で説明されているように監査ログに記録されます。 Dependent Alert Mapping Captured by Audit Log このサポート記事のセクション。

注: 複数のエントリ ポイントに対して単一セットの依存アラート マッピング設定を構成できるということは、おそらく 1 つの構成だけでネットワーク全体をカバーできることを意味します。

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

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

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

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

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


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

注: 使用するエントリ ポイントのトポロジ関係が適切に検出されていることを確認するには、[リソース] ページからエントリ ポイント リソースを開き、[マップ] タブを表示します。 Context フィールドのドロップダウン メニューから [Dynamic] を選択して、複数の分離度を持つ接続を表示します。 見る [マップ]タブ.

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

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

依存関係チェーンの例を示す図
この依存関係チェーンの例では、ノード 1 がエントリ ポイントで、ノード 2 ~ 8 はすべてノード 1 に依存しています。ただし、他の依存関係も同様に存在します。たとえば、ノード 2 がダウンし、その結果ノード 4、6、および 7 が到達不能になった場合、依存アラート マッピングはノード 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によってトリガーされる依存アラートの通知は、ルーティング用にリリースされます。

ほとんどの場合、両方のオプションをオンにして、依存するすべてのアラート ルーティングを抑制し、元の原因を表すと判断されたアラートのみをリリースすることをお勧めします。ただし、より微妙な制御を行う場合は、到達可能性アラートのみ、または到達不能アラートのみを無効にすることができます。これは、異なるチームが異なるタイプのアラートに対処する責任を負っている場合に役立つ可能性があります。

注: アラート通知を抑制するという潜在的に危険な手順を実行する前に、発信元および依存アラートIDの正確性を確認する場合は、最初にこれらのオプションの両方をオフのままにします。 次に、アラートで提供されている根本原因の詳細を使用します。 依存アラート マッピングに固有のアラートの詳細 このサポート記事のセクションを参照して、依存アラート マッピングの結果が期待どおりであることを確認してください。

ルーティング遅延

デフォルトでは、トグル アラートルーティング遅延を有効にする switch is enabled. This delays alert notification routing for all resources that are part of the escalation chain when an alert triggers Dependent Alert Mapping, allowing time for the incident to fully manifest and for the algorithm to determine the originating cause and dependent alerts. An alert’s routing stage indicates “Delayed” while root cause conditions are being evaluated. For more information, see  依存アラートの表示.

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

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

注: エントリポイントリソースの到達可能性またはダウンアラートは、設定に関係なく、常にすぐにルーティングされます。 これは、エントリポイントリソースが常に元の原因であり、アクション可能なアラートであり、即時通知の原因となるためです。

テーブル設定のカスタマイズ

  1. MFAデバイスに移動する  設定 > 警告 依存アラートマッピング
  2. 選択 テーブル設定.
  3. 以下をせよ:
    1. 列を並べ替えるには、  列のサイズ変更アイコン 必要な順序にドラッグします
    2. 列を表示または非表示にするには、 可視性アイコン.

依存アラートの表示

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

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

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

注: 「依存アラート マッピング」列にレポートされる値は、アラートがアクティブな場合にのみ表示されます。これがクリアされると、列内の値はクリアされますが、元の依存アラート マッピングのメタデータは元のアラート メッセージに残ります。

ルーティング状態列

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

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

依存関係の役割の列

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

  • 未定。 「TBD」依存関係の役割は、インシデントがまだ評価中であり、依存関係がまだ決定されていないことを示します。
  • 発信。 「発信元」の依存関係の役割は、アラートがインシデントの根本原因(または根本原因のXNUMXつ)であるリソースを表していることを示します。
  • 依存。 A “Dependent” dependency role indicates that the alert is the result of another alert, and not itself representative of the root cause.

依存アラート列

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

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

LogicMonitor offers two filters based on the data in the Routing State and Dependency Role columns. These filter criteria align with the values available for each column.

You can use the “None” criterion that is available for each of these filters in conjunction with another criterion in order to get an overall view of what your environment considers to be actionable alerts. For example, as shown here, selecting both “None” and “Originating” for the dependency role filter will display all alerts deemed originating via the
Dependent Alert Mapping algorithm as well as all other alerts across your portal that were never assigned a dependency role (i.e. they didn’t undergo Dependent Alert Mapping).

[依存関係]タブ

依存アラート(つまり、発生原因アラートまたは直接原因アラート)を含むアラートの詳細を表示する場合、[依存関係]タブが追加で使用できます。 このタブには、アラートのすべての依存アラート(つまり、依存チェーンの下流にあるリソースのすべてのアラート)が一覧表示されます。 これらの依存アラートは、を使用して確認するか、スケジュールされたダウンタイム(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」のステータス状態にある場合の遅延の開始です

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

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

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

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

Like many other features in the LogicMonitor platform, Dependent Alert Mapping supports role-based access control. By default, only users assigned the default administrator or manager roles will be able to view or manage Dependent Alert Mapping configurations.

記事上で