トポロジマッピングの概要
最終更新日: 30 年 2023 月 XNUMX 日機能の可用性： 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シンセティックスの概要.
トポロジマッピングのコンポーネント
トポロジマップの生成に寄与するいくつかの主要なコンポーネントがあります。
頂点
頂点は、トポロジ内の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リスト](https://www.logicmonitor.com/wp-content/uploads/2019/09/ERI-Listing-on-Info-Tab.png)
カテゴリは、ERIキーが生成されたデバイスまたはテクノロジーのタイプを定義します。 完全なERI生成でカテゴリと優先度がどのように相互作用するかについてのルールは次のとおりです。
- 同じカテゴリ内で、優先度が最も高いERI値のみが保持されます。 同じ優先度を共有する同じカテゴリの値がマージされます
- 完全なERIを作成するために、さまざまなカテゴリの値がまとめられます（カンマ区切り）。
ERT
ERIはリソース/頂点の一意の識別子を指定しますが、外部リソースタイプ（ERT）はそのタイプを指定します。 ERTに割り当てられた値は、レンダリングされたトポロジマップでリソース/頂点を表すために使用されるテクノロジー固有のアイコンを決定します。
Connections
トポロジでは、接続はトポロジ マップ上の XNUMX つの頂点間の関係を表します。 任意の頂点には複数の接続を持つことができます。 ほとんどのシナリオでは、頂点には少なくとも XNUMX つの接続 (送信接続と受信接続) があります。
外向きの接続は、それぞれの頂点に外向きに広がる関係があることを示します。 たとえば、Cisco スイッチの CDP ネイバーを表示するとします。 これを行うには、トポロジ マップ上で「NETWORK」というラベルの付いた発信接続を選択すると、すべての CDP ネイバーが表示されます。 逆に、着信接続は、それぞれの頂点が、別のリソースに適用された TopologySource によって検出されたことを意味します。 提供されたシナリオでは、送信接続「NETWORK」を持つ頂点によって最初に検出されたすべての頂点には、「NETWORK」という名前の受信接続も存在します。
XNUMX つのリソースを接続する接続の名前が接続タイプです。 「NETWORK」の例を続けると、「NETWORK」が接続タイプです。 各接続に対して、存在できる接続タイプは XNUMX つだけです。 XNUMX つのリソース間の同じ接続に複数の名前を付けることはできません。
接続と接続タイプは両方とも TopologySource で定義されます。 TopologySource スクリプトによって生成される JSON ペイロードでは、接続タイプは「Type」として表されます。
トポロジーソース
TopologySource は、特にトポロジ マッピング専用の LogicModule の一種で、スクリプト化された DataSource に似た形式をとります。 TopologySource は、ERI を使用して頂点間の接続を定義します。 TopologySource の正常な出力は、頂点と接続で構成される JSON オブジェクトです。 見る TopologySourceの概要.
ほとんどのネットワークトポロジでは、TopologySourcesはレイヤー2およびレイヤー3の検出プロトコルを利用してVLANに関する情報を収集しています。 この情報は、特定のOID、WMIクラス、およびAPI呼び出しに含まれています。 VMwareの場合、TopologySourcesはvCenter APIにアクセスして、関係情報を収集し、VMMoRefIdsを活用します。
注： まれに、TopologySource が「正常に」実行されることがありますが、結果の関係がマッピング UI に表示されません。 これは、TopologySources を正常に実行するために、AppliedTo リソースに定義された ERI が技術的に必要ないためです。 この問題が発生した場合は、現在 LogicMonitor によって監視されているリソースに ERI を割り当てるために必要な LogicModules (PropertySource や DataSource など) がすべてインポートされていない可能性があります。 を参照してください。 はじめに 要件の詳細なリストについては、このサポート記事のセクションを参照してください。
すべてを結び付けるシナリオの例
次のシナリオ例は、TopologySourcesがERIを使用してリソース間の接続を定義し、トポロジマップをレンダリングする方法を視覚化するために作成されました。
上の図では、TopologySourceが飛行機と飛行機が駐車するハンガーとの関係をどのように調整するかを示しています。図を反時計回りに見ていきましょう。
- 図の右下の TopologySource から始めると、その「レシピ」は、ERI にキー「123333」が含まれるリソースと、ERI にキー「VanGogh」が含まれるリソースを接続することであることがわかります。 これらのリソースが接続されると、「パーキングイン」という接続タイプ (つまり、名前) で接続 (関係) が形成されます。
- 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.名前空間
- トポ.ブラックリスト
リソースにプロパティを割り当てる手順については、を参照してください。 リソースとインスタンスのプロパティ.
topo.namespaceプロパティ
また, topo.名前空間 財産はあなたの最初の防衛線でなければなりません。 このプロパティは、顧客グループなど、さまざまなグループのリソース間でのマージの問題に対処します。 既存のプロパティがtopo.namespaceプロパティに割り当てられ、この名前空間値がリソースのすべてのERIキーの前に追加されます。
これにより、環境間で複製されたキーがERIマージの問題を引き起こしている場合に、これらのリソースに一意のキーが作成されます。 このプロパティは、MSP環境でのトポロジマッピングに特に関係があります。
ほとんどの場合、ルートフォルダレベルでtopo.namespaceプロパティを定義する必要があります。
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&A
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 時間以上など)。