LogicMonitorを始めたとき、私は製品管理について何も知りませんでした。 （はい、はい…しかし、私は以前よりも多くのことを知っています。）私は自分がターゲット顧客であると思って、あらゆる種類の間違いを犯しました。 （驚き！私はそうではありませんでした）。 使いづらい強力な機能を追加しましたが、それは不可欠であり、人々はファインマニュアルを読むだろうと思いました。 （驚きです！多くの人はそうではありません。）私たちは、強力でありながら使いにくい機能を何年にもわたってアクセスしやすくすることで多くの進歩を遂げましたが、私のお気に入りのXNUMXつについて話したいと思います。利点を理解する前に理解する：発見フィルター。 （しかし、男の子、それだけのメリットがあります！）
LogicMonitorは、SaaSデータセンターの運用の伝統に由来します。ここでは、ほとんどすべてが重要であり、エラーが発生した場合は警告する必要があります。 しかし、それはすべての展開に当てはまるわけではありません。顧客が企業のネットワーキング部門にいる場合は、 コアスイッチの監視、ただし、ディストリビューションネットワークスイッチの場合、スイッチのアップリンクポートは確かに重要ですが、エンドユーザーのワークステーションに接続するスイッチポートは重要ではありません。 LogicMonitorは、デフォルトで、スイッチポートのステータスが変化するため、エンドユーザーがコンピューターの電源を切るたびに警告を発します。 ワークステーションがポートのサブスクライブをやり直して破棄を引き起こした場合、警告が表示されます。 （サーバーポートで知りたいが、エンドユーザーポートでは知りたくないこと。）
では、LogicMonitorがディストリビューションスイッチに過度のノイズを発生させないようにしながら、必要なデータとアラートを提供するにはどうすればよいでしょうか。 ディスカバリーフィルター！
検出フィルターは、ホスト上で監視するために検出されるオブジェクトを制御するだけです。 これらは、オブジェクトが検出されるために満たす必要のある一連の条件を指定します。 例：通常、ダウンしたインターフェースの状態を監視する必要はないため、インターフェースのデータソースには次のフィルターがあります。
これは単に、SNMPを介してインターフェイスのテーブルをたどるときに、検出された各インターフェイスのインターフェイスステータスがOIDで照会されることを意味します。 インターフェイスがフィルタを通過して検出されるためには、そのステータスが「1」である必要があります。 そのため、ダウンしている、またはテスト中のインターフェイスは検出されないため、気にしないインターフェイスでホストが乱雑になることはありません。 （また、Active Discoveryは定期的に実行されるため、後でインターフェイスを起動すると、テストに合格し、監視されます。）
使用例：スイッチのエッジポートとアップリンクポートの扱いが異なります。
では、ディストリビューションスイッチのユースケースに戻りましょう（今週のクライアントとの会話の実際の例）。 Ciscoスイッチが使用され、アップリンクポートはスイッチポートの説明で一貫して「アップリンク」とラベル付けされ、エッジポートは少なくともその文字列ではラベル付けされていませんでした。
単純なケースは、説明に文字列「Uplink」が含まれているインターフェイスのみを渡すように検出フィルタを追加することです。 例えば：
（1.3.6.1.2.1.31.1.1.1.18がインターフェイスの説明（技術的にはインターフェイスエイリアス）を文字列として返すことをどのようにして知りましたか？この場合、アクティブディスカバリセクションで説明フィールドとして使用されていたため、明らかでしたが、そうでなければ、MIBブラウザで検索する必要がありました。）
この単純なアプローチにはXNUMXつの問題があります。エッジポートを監視したいが、アラート設定が異なる場合はどうなるでしょうか。 そしてさらに重要なことに、これはからの発見を防ぎます を インターフェイスにアップリンクの説明がない限り、デバイスなど。これにより、サーバーなどでインターフェイスが検出されなくなる可能性があります。
解決策：データソースとAppliesToフィールドのクローンを作成します。
標準のインターフェイスデータソースは、SNMPに応答するすべてのデバイスに適用されますが、ネットワーク機器に追加のフィルタリングを適用するだけです。 最終的に必要なのは、XNUMXつではなくXNUMXつのデータソースです。XNUMXつはCiscoデバイスに適用され、アップリンクのみを検出します。 もうXNUMXつは、Ciscoデバイスに適用され、アップリンク以外のすべてを検出します。もうXNUMXつは、他のすべてに適用されます。 これはそれを達成するためのプロセスです：
- [ホスト]タブからネットワークデバイスを見つけ、[インターフェイス（64ビット）]の横にあるツールアイコンをクリックして、[データソース定義の編集]を選択します。
- 開いたページで、データソースのクローンを作成します。右側のナビゲーションツリーでデータソースを右クリックし、[クローン]を選択します。 新しいデータソースにわかりやすい名前と表示名を付けます（例：インターフェイス（64ビット）アップリンク）。
- 編集 に適用されます UplinksデータソースがCiscoデバイスにのみ適用されるようにフィールドを設定します。
- アップリンクのみが検出されるように、検出フィルターを追加します。 インターフェイスの説明で「アップリンク」を使用する場合は、上記の例に従うことができますが、ネットワークインフラストラクチャで採用する標準に応じて、これを行う方法は多数あります。 たとえば、スイッチのポート45、46、47、および48を常にアップリンクとして使用する場合は、インターフェイスの説明に対してフィルタを追加できます。
送信します。 - これで、アップリンクのみを検出するデータソースができました。 非アップリンクも監視する場合は、プロセスを繰り返すことができます。新しいデータソースのクローンを作成し、インターフェイス（64ビット）エッジポートという名前を付け、[適用先]をIsCisco（）に設定します（[適用先]フィールドは、クローン作成プロセス。）次に、フィルターを逆に設定します。 たとえば、Contains Uplinkの代わりに、テストNotContains Uplink（またはRegexNotMatch 4 [5678]）を使用します。 また、このデータソースのアラートを調整する必要があります。特に、StatusおよびStatusFlappingデータポイントのしきい値を削除します。
- 最後に、通常のインターフェイスデータソースがこれらのインターフェイスも監視しないようにする必要があります。 これは、[適用先]フィールドを「hasCategory（ "snmp"）&&！isWindows（）&&！isCisco（）」に設定することで簡単に実現できます（つまり、このデータソースをSNMPをサポートするすべてのホストに適用しますが、WindowsホストではなくCiscoホストではありません。）
それでおしまい。 LogicMonitorをカスタマイズして、スイッチのアップリンクポートをインテリジェントに検出できるようになりました。 監視のためにエッジポートを検出しますが、それらへのアラートは少なくなります。 それ以外はすべてデフォルトのインターフェース監視を使用します。 すべてのニーズに合わせて簡単に調整できます。
検出フィルターはさまざまな方法で使用できます（ストレージアレイ上のQAボリュームの検出は、本番ボリュームとは異なるため、自動的に異なるしきい値を設定できます。ロードバランサーでVIPを自動的に分類するなど）。優れている点は、一元的に使用できることです。企業全体でオブジェクトを分類するためのルールを定義し、それらのデバイスでデバイスとオブジェクト（インターフェイス、VIP、ボリュームなど）を追加および削除する場合でも、自動的に適用します。
実装した（または設定のヘルプを使用できる）フィルタリングの興味深いユースケースを手に入れましたか？ コメント欄でお知らせください。