トポロジマッピングの概要| LogicMonitor

製品ドキュメント

トポロジマッピングの概要

機能の可用性： LogicMonitorProおよびEnterprise

トポロジマッピングは、通信ネットワーク内の要素間の関係を視覚的に表現したものです。トポロジマップは、一般にレイヤ1マッピングと呼ばれるネットワークコンポーネントの物理的な場所を表すことも、レイヤ2マッピングと呼ばれる接続された要素間の伝送関係を表すことも、マルチのルーティングとトラフィック制御の側面を表すこともできます。 -ノードネットワーク。レイヤー3マッピングと呼ばれます。

LogicMonitorのトポロジマッピング機能は、レイヤー2およびレイヤー3のマッピングに重点を置いています。具体的には、LogicMonitorプラットフォームは、Link Layer Discovery Protocol（LLDP）、Cisco Discovery Protocol（CDP）、Border Gateway Protocol（BGP）、Open Shortest Path First（OSPF）、およびEnhanced Interior Gateway Routing Protocol（EIGRP）を活用して、ネットワークトポロジを動的に生成します。環境内の多くのリソース（スイッチ、ホスト、ファイアウォール、ルーター、およびその他のネットワークコンポーネント）間でデータがどのように流れるかを示すマップ。

LogicMonitorは、トポロジマップを生成するために付加的なアプローチを取ります。このアプローチは、最初は目前の現在のタスクに最も関連する関係のみを示しますが、外側に拡張することもできます。トポロジマップの作成、保存、およびダッシュボードへの追加の詳細については、を参照してください。マッピングページ.

LogicMonitorのトポロジマッピングが提供するコンテキストは、監視操作に非常に役立ち、次の機能を提供します。

トポロジの関係に基づいてリソースを視覚化し、ナビゲートします
依存リソースに影響を与えているインシデントの根本原因をすばやく特定します（オプションで、発信元のアラートに依存していると判断されたアラートのアラート通知ルーティングを抑制します）。見る根本原因分析の有効化を参考にしてください。
トポロジマップ上のインフラストラクチャ内のアラートのトラブルシューティング
アラートに基づいてトポロジマップを生成し、トラブルシューティングワークフローを合理化します
リソース間の関係を発見してマッピングする
継続性を監視するために、関連性のある頻繁に使用されるトポロジマップを保存します

始めに

トポロジマッピングを有効にするには、次に概説するように、必要なすべてのLogicModuleがインポートされて最新であることを確認する必要があります。

LogicMonitorリポジトリから、すべてのTopologySourceをインポートします。で説明されているようにトポロジーソースこの記事のセクションであるTopologySourcesは、トポロジマッピング用に特別に作成されたLogicModuleの一種です。 
LogicMonitorリポジトリから、関連するすべてのPropertySourceをインポートします。これらには以下が含まれます：
- addERI_ *。 「addERI_」で始まるすべてのPropertySource（例：addERI_Cisco、addERI_Vcenterなど）。 
- addCategory_TopoSwitch。 このPropertySourceは、LogicMonitorがネットワークTopologySourcesに適したリソースを識別するのに役立ちます。
一部のタイプのリソース、特にVMwareとKubernetes（他にもあります）の場合、データソースにはトポロジマッピングに関するいくつかの命令が含まれています。このため、プラットフォームで使用されているすべてのデータソースが最新であることを確認することをお勧めします。 重要： データソースの更新をインポートすると、モジュールに対して行ったカスタマイズが上書きされる可能性があるため、インポートする前に（diffビューアを介して）更新を慎重に評価することをお勧めします。

これらの手順を完了すると、新しくインポートされたTopologySourcesは、トポロジマップを動的に生成するために、ERIキーの接続を開始し、LogicMonitorによって現在監視されているすべてのリソース間の関係を形成します。トポロジマップは、で説明されているように、[マッピング]ページから作成、保存、およびダッシュボードに追加できます。マッピングページ.

注意：

デフォルトでは、デフォルトの管理者およびマネージャーの役割が割り当てられているユーザーのみが、最初にトポロジマップをレンダリングできます。トポロジマッピングに使用できるアクセス許可の詳細については、を参照してください。トポロジマッピング機能の役割ベースのアクセス制御このサポート記事のセクション。
セレン合成チェックのトポロジマッピング機能を追加できます。合成チェックの詳細については、次を参照してください。 LMシンセティックスの概要.

トポロジマッピングのコンポーネント

トポロジマップの生成に寄与するいくつかの主要なコンポーネントがあります。

頂点
外部リソースID（ERI）および外部リソースタイプ（ERT）
エッジ
トポロジーソース

頂点

頂点は、トポロジ内のXNUMXつ以上のリソースを表すLogicMonitor内の論理オブジェクトです。頂点は、頂点によって表される基になるリソースに割り当てられている外部リソースID（ERI）と外部リソースタイプ（ERT）によって識別されます。

外部リソースID（ERI）および外部リソースタイプ（ERT）

次のセクションで説明するように、ERIとERTは、デバイス、インスタンス、およびサービス（LogicMonitorプラットフォームではリソースと総称されます）に設定されるプロパティであり、トポロジマップに含めるためにリソースを認識できるようにします。リソースのERIとERTはどちらも、PropertySource（デバイスレベルのERIプロパティの場合）またはDataSource（インスタンスレベルのERIプロパティの場合）のいずれかによって定義されます。

ERI

ERIには、リソースを一意に識別するのに役立つ一連のキーが含まれています。 XNUMXつのERIは多くのキーで構成でき（すべてのキーはERI自体にCSVとして格納されます）、キーは次のXNUMX種類の識別子のいずれかを表します。

メディアアクセス制御（MAC）アドレス
インターネットプロトコル（IP）アドレス
完全修飾ドメイン名（FQDN）

ERI優先

複数のPropertySourceまたはDataSourceがリソースまたはインスタンスのERIキーを生成する可能性があります。これが発生すると、LogicMonitorは信頼アルゴリズムを使用して、どのERIが優先されるかを決定します。

カテゴリごとに生成されたすべてのERIは、各ERIを構成する個々のキーとともに、[情報]タブ（[リソース]ページから利用可能）に表示され、完全なERI（の値として保存）に関する洞察を提供します。 predef.externalresourceid プロパティ）優先順位の決定に基づく生成。割り当てられた優先順位番号が最も高いERI値（つまり、リストの一番上にあるERI）が優先され、TopologySourcesを介して関係をマッピングするために使用される完全なERIを生成するために使用されます。

カテゴリは、ERIキーが生成されたデバイスまたはテクノロジーのタイプを定義します。完全なERI生成でカテゴリと優先度がどのように相互作用するかについてのルールは次のとおりです。

同じカテゴリ内で、優先度が最も高いERI値のみが保持されます。同じ優先度を共有する同じカテゴリの値がマージされます
完全なERIを作成するために、さまざまなカテゴリの値がまとめられます（カンマ区切り）。

ERT

ERIはリソース/頂点の一意の識別子を指定しますが、外部リソースタイプ（ERT）はそのタイプを指定します。 ERTに割り当てられた値は、レンダリングされたトポロジマップでリソース/頂点を表すために使用されるテクノロジー固有のアイコンを決定します。

エッジ

トポロジでは、エッジはトポロジマップ上のXNUMXつの頂点間の関係を表します。任意の頂点は複数のエッジを持つことができます。ほとんどのシナリオでは、頂点には少なくともXNUMXつのエッジがあります。XNUMXつは発信エッジで、もうXNUMXつは着信エッジです。

発信エッジは、それぞれの頂点が外側に発している関係を持っていることを示します。たとえば、CiscoスイッチのCDPネイバーを表示するとします。これを行うには、トポロジマップで「NETWORK」というラベルの付いた発信エッジを選択すると、すべてのCDPネイバーが表示されます。逆に、入力エッジは、それぞれの頂点が別のリソースに適用されたTopologySourceによって検出されたことを意味します。提供されたシナリオでは、発信エッジが「NETWORK」の頂点によって最初に検出されたすべての頂点にも、「NETWORK」という名前の着信エッジがあります。

XNUMXつのリソースを接続するエッジの名前はエッジタイプです。「NETWORK」の例を続けると、「NETWORK」がエッジタイプです。すべてのエッジに対して、エッジタイプはXNUMXつだけです。 XNUMXつのリソース間の同じエッジに複数の名前を付けることはできません。

エッジとエッジタイプはどちらもTopologySourceで定義されています。 TopologySourceスクリプトによって生成されたJSONペイロードでは、エッジタイプは「タイプ」として表されます。

トポロジーソース

TopologySourcesは、トポロジマッピング専用のLogicModuleの一種であり、スクリプト化されたデータソースに似た形式を取ります。 TopologySourcesは、ERIを使用して頂点間の接続を定義します。 TopologySourceの正常な出力は、頂点とエッジで構成されるJSONオブジェクトです。見る TopologySourceの概要.

ほとんどのネットワークトポロジでは、TopologySourcesはレイヤー2およびレイヤー3の検出プロトコルを利用してVLANに関する情報を収集しています。この情報は、特定のOID、WMIクラス、およびAPI呼び出しに含まれています。 VMwareの場合、TopologySourcesはvCenter APIにアクセスして、関係情報を収集し、VMMoRefIdsを活用します。

注意： まれに、TopologySourcesは「正常に」実行できますが、結果の関係がマッピングUIに表示されません。これは、TopologySourcesが正常に実行するためにAppliedToリソースで定義されたERIを技術的に必要としないためです。これが発生した場合は、LogicMonitorによって現在監視されているリソースにERIを割り当てるために必要なすべてのLogicModule（PropertySourcesやDataSourcesなど）をインポートしていない可能性があります。を参照してください始めに要件の詳細なリストについては、このサポート記事のセクションを参照してください。

すべてを結び付けるシナリオの例

次のシナリオ例は、TopologySourcesがERIを使用してリソース間の接続を定義し、トポロジマップをレンダリングする方法を視覚化するために作成されました。

上の図では、TopologySourceが飛行機と飛行機が駐車するハンガーとの関係をどのように調整するかを示しています。図を反時計回りに見ていきましょう。

図の右下にあるTopologySourceから始めて、その「レシピ」は、ERIにキー「123333」が含まれているリソースと、ERIにキー「VanGogh」が含まれているリソースを接続することであることがわかります。これらのリソースが接続されると、「Parking-In」のエッジタイプ（つまり名前）でエッジ（関係）が形成されます。
TopologySourceのすぐ上に、TopologySourceによって参照されるキーを含むERIがあるものとして、メイン格納庫、ボーイング、エアバスのXNUMXつのリソースが識別されています。これらのリソースのうちXNUMXつは、外部リソースタイプ（ERT）が「飛行機」で、XNUMXつはERTが「格納庫」です。 XNUMXつの異なるデータソースがこれらのERI / ERTをそれぞれ割り当てました。
左に移動すると、バックエンドでトポロジマップがどのようにモデル化されているかがわかります。左上に、XNUMXつの飛行機リソースを表す頂点がXNUMXつしかないことに注意してください。で説明されているように ERIマージこのサポート記事のセクションでは、LogicMonitorはトポロジマップをレンダリングするときに重複するERIキーを探します。同じERIキーがXNUMXつ以上のリソースに割り当てられている場合（ここの場合のように、両方がERIキー「Riverland」を共有します）、それらは単一の頂点にマージされます。頂点がマージされたリソースを表す場合、その表示名はERIが最小のリソースの表示名になり、そのERTはアルファベット順に最初に来るものになります。
続けて、メイン格納庫リソースは、変更なしで頂点としてモデル化されます。
そして最後に、図の最終結果は、「駐車場」という名前のエッジによって定義された、エアバスとそのメイン格納庫の間の接続です。

VMwareへの外挿例

次に、前に強調した単純で非現実的な例から、LogicMonitorの操作に関連する可能性が高い例（VMwareコンポーネント間のトポロジのマッピング（vCSA→クラスター→ホスト→VM→など））から外挿してみましょう。 VMwareの場合、データソースは管理対象オブジェクト参照ID（MoRef）とMACアドレスの両方をリソースERIキーとして割り当てます。

たとえば、ERIスクリプトの結果は次のようになります。 predef.externalresourceid = 10.41.16.7–host-1981, 00:21:28:6b:09:dc、ここで、ホストIDはvCenterのIPv4アドレスに追加され、MACアドレスもERIキーとしてリソースに割り当てられます。 MoRefをERIキーとして割り当てると、vCenterAPIを利用して複数の関係を定義できます。 MACアドレスは、ホストをネットワークに結び付け、接続先のスイッチを示すために使用されます。

TopologySourceは、仮想マシン、ハイパーバイザー、クラスター、vCSAなどに割り当てられたERIキーを接続しようとします。 LogicMonitorがこれらのコンポーネント間で重複するERIキーを検出した場合（たとえば、vCenterを介してVMを監視している場合、および個別のリソースとしてSNMPを介して監視している場合）、トポロジマップによってレンダリングされるときに単一の頂点にマージされます。

トポロジマッピング機能の役割ベースのアクセス制御

トポロジマッピングは、LogicMonitorプラットフォームの他の多くの機能と同様に、役割ベースのアクセス制御をサポートします。デフォルトでは、デフォルトの管理者およびマネージャーの役割が割り当てられているユーザーのみが、トポロジマップをレンダリングし、トポロジマッピング機能の全範囲にアクセスできます（読み取り専用の役割が割り当てられているユーザーには、[マッピング]ページと保存されているマップが表示されます）。で説明したように役割、ロールを作成/更新して、トポロジマッピング機能への完全または制限付きアクセスを可能にすることができます。

カスタムトポロジマッピング関係の作成

大多数のユーザーの場合、関連するすべてのファイルがインポートされていれば、カスタムTopologySourceを作成したり、ERIとERTを手動で割り当てたりする必要はありません。トポロジは自動的に検出され、トポロジマップが動的に生成されます。

ただし、データソースと同様に、LogicMonitorプラットフォームは、新しい（または既存の）TopologySourceを作成する機能を公開します。同様に、データソースやPropertySourceを作成または変更して、カスタムERIおよびERTを割り当てることができます。これは複雑なプロセスであり、一意のERIの確保とスクリプトの作成を慎重に検討する必要があるため、サポートチームに連絡してガイダンスを求めることをお勧めします。

トポロジマップでの不正確なリソース表示のトラブルシューティング

トポロジマップをレンダリングするとき、LogicMonitorはリソース間で重複するERIキーを探します。同じERIキーがXNUMXつ以上のリソースに割り当てられている場合、これらのリソースはXNUMXつの頂点にマージされ、その表示名はERIが最小のリソースの表示名になり、そのERTはアルファベット順で最初に表示されます。

LogicMonitorは、この方法でリソースをマージして、同じリソースがトポロジマップ上で複数回表されないようにします。 LogicMonitorには、リソースを複数回監視する柔軟性があり、多くの場合、異なるテクノロジドメイン（SNMP / WMIやVMのvCenterなど）を使用するため、そのリソースをまとめて表す方法が必要です。

ただし、ERIのマージによって予期しない結果が発生し、トポロジマップに誤ったリソースが表示される場合があります。これらのERIキーマージの問題に対処するために、LogicMonitorにはXNUMXつのプロパティがあります。

topo.namespace
topo.blacklist

リソースにプロパティを割り当てる手順については、を参照してください。リソースとインスタンスのプロパティ.

topo.namespaceプロパティ

topo.namespace 財産はあなたの最初の防衛線でなければなりません。このプロパティは、顧客グループなど、さまざまなグループのリソース間でのマージの問題に対処します。既存のプロパティがtopo.namespaceプロパティに割り当てられ、この名前空間値がリソースのすべてのERIキーの前に追加されます。

これにより、環境間で複製されたキーがERIマージの問題を引き起こしている場合に、これらのリソースに一意のキーが作成されます。このプロパティは、MSP環境でのトポロジマッピングに特に関係があります。

ほとんどの場合、ルートフォルダレベルでtopo.namespaceプロパティを定義する必要があります。

topo.blacklistプロパティ

topo.blacklist プロパティは、特定のERIキーの検討を禁止します。たとえば、MACアドレスが複数のリソース間で重複していて、誤ったマージが発生した場合、そのアドレスをtopo.blacklistプロパティの値として入力して、ERIキー生成での使用から除外できます。

該当する場合は、topo.blacklistプロパティを使用する前に、topo.namespaceプロパティを使用して誤ったマージの問題を解決してください。ただし、ERI除外を介してのみ対処できる問題については、このプロパティをルート、グループ、またはリソースレベルで設定します（可能な限り深いレベルで設定することをお勧めします）。

注意： topo.namespaceプロパティがtopo.blacklistプロパティと組み合わせて使用されている場合は、topo.blacklistプロパティに割り当てられた値に、topo.namespaceプロパティによって割り当てられた名前空間プレフィックスが含まれていないことを確認してください。

topo.blacklistプロパティをローカルで使用する場合は、ユースケースを報告するためにサポートに追加で連絡することをお勧めします。これにより、お客様の環境におけるこのプロパティの有効性を評価できるだけでなく、お客様のユースケースが他のユーザーに適用される可能性があるかどうかを判断できるため、製品によって正式に対処されます。

重複するERIキーのデバッグコマンド

XNUMXつのコマンドがから利用可能ですコレクターデバッグ機能これにより、重複するERIキーの存在に関連する問題をデバッグできます。

！erimergelist [threshold = xxx] –このコマンドは、リソース/インスタンス全体に表示されるすべてのERI値（または指定されている場合は指定されたしきい値を満たす値）を一覧表示します。
！erimergedetail –このコマンドは、ERI値にバインドされているすべてのリソース/インスタンスを一覧表示します

よくある質問

Q：TopologySourceがエッジを報告していますが、UIが同じものを反映していません。
A: ERIが適用され、正しいリソースにヒットしていることを確認してください。 TopologySourcesは、ERIスクリプトとは独立した関係を報告します。これにより、ユーザーは、トポロジーがUIでも使用可能である必要があると考えるようになります。

Q：適切な資格情報が設定されていても、TopologySourcesが正常に実行されません。
A: SNMPベースのTopologySourceの場合、一部のOIDがデバイスでクエリできないことが確認されています。例：ジュニパースイッチにCDP（Cisco Discovery Protocol）を照会します。

Q：私のネットワークトポロジは、ネットワークが実際にどのように配置されているかとは関係ありません。
A: ネットワークパスにあるすべてのリソースがLogicMonitorによって監視されていること、および適切な資格情報（snmp、wmi、esx.user、esx.passなど）とプロトコルが有効になっていることを確認してください。

Q：予想とは異なる表示名の頂点が表示されます。
A: これは、XNUMXつ以上のリソースが同じERIキーを持っている結果としてリソースがマージされたことが原因である可能性があります。 ERIのマージの詳細については、 ERIマージこのサポート記事のセクション。

Q：リソースごとにマップを追加する必要がありますか？
A: いいえ。単一のマップをモデル化して、適切と思われるリソースの論理グループを含めることができます。これは、顧客サイト、特定のビジネスユニット、サービスが実行されるサポートインフラストラクチャなどです。

Q：TopologySourceによって生成された負荷は、コレクターに過度の負担をかけますか？
A: SNMP、WMI、APIなどのプロトコルを使用して関係データを収集しているため、コレクターの負荷を増やす必要があります。ただし、収集しているデータはメトリックデータではないため、ポーリング間隔を大幅に短縮できます（たとえば、シナリオによっては1時間以上）。

プライバシーの概要

製品ドキュメント