アクティブディスカバリーとは何ですか?

最終更新日: 13 年 2022 月 XNUMX 日

Active Discoveryは、LogicMonitorが特定のシステム上の特定のタイプの同様のコンポーネントをすべて判別するプロセスです。 Active Discoveryプロセスの出力は、LogicMonitorが特定のタイプのデータを収集できるXNUMXつ以上のインスタンスです。

リソースツリーから見たインスタンスの拡張セット
インスタンスは、リソースツリーの親データソースの下に編成されています。

Active Discoveryは、環境の変化に応じて監視を最新の状態に保つために非常に役立ちます。 たとえば、Active Discoveryは、仮想化スタック上に作成された新しいVMがそれぞれ検出および監視されるようにしたり、ストレージシステムに追加された新しいボリュームがそれぞれ検出および監視されるようにします。 Active Discoveryがないと、実稼働環境に変更を加えるたびに、監視インスタンスを手動で更新することを忘れないでください。

アクティブディスカバリ実行

Active Discoveryが有効になっているデータソースには、ActiveDiscoveryの実行間の時間を定義する検出スケジュールがあります。 この検出スケジュールは、データソース定義から構成されます( ActiveDiscoveryの構成 このサポート記事のセクション)であり、データソースごとに異なります。 たとえば、通常はあまり頻繁に変更されないオブジェクト(たとえば、システム内のファンまたはCPUの数)には、LogicMonitorによってXNUMX日XNUMX回の検出スケジュールが割り当てられます。 ただし、より頻繁に変更される可能性のあるオブジェクト(NetAppディスクアレイ上のボリュームなど)には、XNUMX時間に数回の検出スケジュールが割り当てられます。

データソース定義で定義されたスケジュールに従って実行することに加えて、自動検出は次の場合に追加で実行されます。

  • デバイス(またはデータソース)が監視に追加されます。
  • デバイスまたはデータソースのプロパティ/構成が変更されます。
  • リソースページから手動で開始されます。 Active Discoveryを手動で実行する機能は、デバイスに新しいオブジェクトを追加し、スケジュールされたActive Discoveryの実行を待たずに、LogicMonitorが監視のためにすぐにそれを取得するようにしたい場合に役立ちます。 Active Discoveryを手動で実行する方法の詳細については、を参照してください。 インスタンスの追加.

注: 特定のリソースまたはリソースのグループのデータソース監視を無効にした場合( データソースまたはインスタンスの監視を無効にする)、ActiveDiscoveryもそのデータソースに対して無効になっています。 これは、影響を受けるリソースのインスタンスが検出、更新、または削除されないことを意味します。

ActiveDiscoveryによって収集された情報

Active Discoveryは、検出したインスタンスごとに次の情報を取得します。

  • インスタンス名。 リソースツリーに表示される「ALIAS」とも呼ばれる、インスタンスの説明的な名前(Fastethernet0など)。 この値は、デバイスとデータソースの組み合わせに対して一意である必要があります。
  • インスタンスID。 インスタンスの一意のID。デバイスにデータを照会するときにこのインスタンスを識別するための変数として使用されます(たとえば、SNMP OIDツリーの変数部分、またはストレージシステムのボリュームID)。 これは「WILDVALUE」とも呼ばれます。
  • インスタンスの説明。 インスタンスのオプションの説明。これは、リソースツリーにインスタンス名とともに表示されます。
  • インスタンスのプロパティ。 インスタンスに関する静的データを提供するキーと値のペアのオプションのセット。 これらはに類似しています リソースのプロパティ、ただし、インスタンスごとに収集されます。 収集されると、インスタンスのプロパティが保存され(UIに表示され)、キーとして使用できます。 グループインスタンス 一緒に、またはの一部として 複雑なデータポイント 計算。 次のプロパティは、通常、インスタンスプロパティとして収集されます。
    • スイッチシャーシまたはストレージシステムのドライブで検出された各FRUのシリアル番号。
    • ハイパーバイザーによってホストされる各VMのメタデータ(CPU数、メモリ割り当て、仮想NIC数、ゲストOSなど)。
    • 各ネットワークインターフェイスのポート速度。

    注: インスタンスプロパティの収集は、スクリプト、SNMP、またはWMIクエリメソッドを使用するActiveDiscoveryプロセスでのみ使用できます。

    注: Active Discoveryを介してインスタンスのプロパティを収集することに加えて、で説明されているように、インスタンスにプロパティを手動で割り当てることもできます。 リソースとインスタンスのプロパティ.

ActiveDiscoveryの構成

Active Discoveryは、データソースごとに構成されます。 したがって、データソース定義から構成されます。 データソース定義は、監視に関連する多くの構成を制御します。詳細については、 データソースの作成.

データソースのアクティブディスカバリーを構成するには、に移動します。 設定| LogicModules | データソース データソースを開きます。 Active Discoveryの見出しまで下にスクロール(および展開)して、使用可能なすべてのActiveDiscovery設定を表示します。 次に、それぞれについて説明します。

注: データソースはマルチインスタンスである必要があります(つまり、 マルチインスタンス Active Discoveryを構成するには、[一般情報]見出しの下で[オプション]をオンにする必要があります。

アクティブディスカバリーを有効にする

チェック アクティブディスカバリーを有効にする アクティブディスカバリーを有効にするオプション。 有効にすると、LogicMonitorは、データソースが適用されるデバイス上のデータソースのインスタンスを自動的に検出します。

検出されたインスタンスを無効にする

Status 検出されたインスタンスを無効にする オプションをオンにすると、インスタンスは検出時に最初は無効な状態になり、動的な「監視されていない」インスタンスグループに自動的に移動します(を参照)。 インスタンスグループ インスタンスグループの詳細については)。 これらのインスタンスでは、監視を手動で有効にする必要があります。

このオプションをオンにすると、監視を有効にする前にインスタンスのデータポイントのしきい値を微調整する場合に役立ちます。 これにより、新しいインスタンスが検出されるとすぐに、不要なアラートが大量に受信されることはありません。

インスタンスを自動的に削除する

Status インスタンスを自動的に削除する オプションがチェックされている場合、将来のActive Discoveryの反復でインスタンスがデバイスに存在しなくなったことが報告された場合、LogicMonitorはインスタンスを監視から自動的に削除します。

インスタンスが存在しない場合でもアラートを受信する場合は、ベストプラクティスとして、このオプションのチェックを外してください。 たとえば、Active Discoveryが、リスニングTCPポートを見つけることによってサービスを監視する必要があることを検出した場合、このオプションをチェックしたくない場合があります。 これは、サービスに障害が発生した場合、ポートが応答を停止し、Active Discoveryがインスタンスを存在しないことを報告し、監視から削除され、アラートを受信しなくなるためです。そのためのアラートを受信したいと思います。

監視からインスタンスを自動的に削除する場合、監視履歴をLogicMonitorに保持する期間を選択できます。

  • すぐに削除します。 インスタンス(およびそのすべての監視履歴)は、インスタンスが存在しないと判断されるとすぐにLogicMonitorから削除されます。
  • 30日後に削除します。 インスタンスは、存在しないと判断されるとすぐにリソースツリーから消えますが、その監視履歴は、削除される前に30日間LogicMonitorに残ります。 この30日のウィンドウ内にインスタンスが再検出された場合、以前の監視履歴は再検出時に再関連付けされます。 この猶予期間は、障害が発生したネットワークカードの交換など、新しいカードがアクティブになったときに古い履歴を表示したい場合に役立ちます。 (新しいインスタンスが古いインスタンスに関連していない場合は、履歴を保持したくないでしょう。)

発見スケジュール

で説明したように アクティブディスカバリ実行 このサポート記事のセクションで、Active Discoveryは、15分ごと、XNUMX時間ごと、またはXNUMX日XNUMX回のスケジュールで実行するように構成できます。 または、実行するように構成できます データソースが最初にデバイスに適用されたとき、またはデータソース(またはデータソースが適用されたデバイス)が何らかの方法で更新されたとき。

発見方法

  発見方法 フィールドは、インスタンスを検索するためにActive Discoveryで使用される方法(SNMP、WMI、スクリプトなど)を定義します。 LogicMonitorのActiveDiscoveryプロセスは、監視に使用できるオブジェクトについてデバイスまたはシステムにクエリを実行するためのさまざまな方法をサポートしています。 これらには以下が含まれます:

  • CIM。 Common InformationModelのクラスとプロパティを照会します。
  • コレクタ。 コレクターをインスタンスとして検出します。
  • HTTP。 HTTP / HTTPSURLを照会します。
  • JDBC。 データベースクエリを起動します。
  • JMX。 特定のJavaManagementExtensionsパスを照会します。
  • パーモン。 WindowsPerfmonクラスを照会します。
  • ポート。 特定のTCPポートに接続します。
  • 脚本。 スクリプトの出力を使用します。
  • SNMP SNMPクエリを起動します。
  • WMI。 WindowsWMIクラスを照会します。
  • さまざまなAPI。 一部のシステムおよびアプリケーションでは、LogicMonitorは、Citrix XenServer API、MongoDBAPIなどの独自のAPIの直接クエリを介してActiveDiscoveryをサポートします。 ネットアップ API、およびVMware ESXAPI。
  • さまざまなパブリッククラウドリソース。 パブリッククラウドリソースの場合、LogicMonitorは、Amazon Web Services(AWS)、Google Cloud Platform(GCP)、MicrosoftAzureによってホストされているものを含む独自のクラウドシステムの直接クエリを介してActiveDiscoveryをサポートします。

計測パラメータ

「パラメータ」の見出しの下で使用可能なオプションは、選択した検出方法に応じて動的に更新されます。 さまざまな検出方法に必要な一意のパラメータの設定の詳細については、 個別のサポート記事.

フィルタ

フィルタを使用すると、ActiveDiscoveryを介して監視に追加されるインスタンスを制限できます。 XNUMXつ以上のフィルターが配置されている場合、インスタンスを検出するには、インスタンスがフィルター基準に一致する必要があります。

フィルタを作成するには、プラス記号(+)アイコンを表示し、特定の属性が満たす必要のある条件を指定します。 属性は、インスタンスレベルのプロパティ、SNMP OID、またはWMIクエリ出力にある属性を表すことができます。

注: フィルタステートメントを作成する場合、次のようないくつかの標準操作タイプ Equal, NotEqual, LessThan, Contain, RegexMatch (いくつか例を挙げると)利用可能です。 これらのほとんどは自明ですが、私たちが目にする一般的な混乱のXNUMXつのポイントは、 Contain 文字列にAまたはBが含まれるインスタンスが検出されることを前提とした、「A | B」などの値をフィルタリングします。 ただし、値は Contain 操作は単一の文字列として検索され(「A | B」は文字通り存在する必要があります)、 RegexMatch ORステートメントが必要な場合は、演算を使用する必要があります。

ジョブの設定方法については、 アクティブディスカバリーフィルターについて ActiveDiscoveryフィルターの実際のユースケースシナリオに関するこのサポート記事のセクション。

グループ方式

  グループ方式 フィールドは、検出時にインスタンスがどのように編成されるかを決定します。 グループ方式として「手動」を選択して、検出後にインスタンスを手動でグループに編成する(または永続的にグループ化しないままにする)か、ドロップダウンから使用可能な自動グループ化方式のXNUMXつを選択できます。 インスタンスグループの管理の自動化の詳細については、を参照してください。 インスタンスグループ.

アクティブディスカバリーフィルターについて

Active Discoveryフィルターは、デバイスレベルでインスタンスとして入力できるオブジェクトを制御します。 これらのフィルターは、必要なアラートとデータ収集を維持するために使用されますが、重要でないインフラストラクチャでのアラートを防ぎます。 フィルタが設定されている場合、アクティブ検出プロセスを介して検出されたすべてのオブジェクトは、監視に追加されるためにフィルタ基準を満たす必要があります。

注: 複数のフィルターラインは、論理AND演算子を使用して結合されます。 検出されたインスタンスを監視に追加するには、すべてのフィルターの基準を満たす必要があります。

注: フィルタステートメントを作成する場合、次のようないくつかの標準操作タイプ Equal, NotEqual, LessThan, Contain, RegexMatch (いくつか例を挙げると)利用可能です。 これらのほとんどは自明ですが、私たちが目にする一般的な混乱のXNUMXつのポイントは、 Contain 文字列にAまたはBが含まれるインスタンスが検出されることを前提とした、「A | B」などの値をフィルタリングします。 ただし、値は Contain 操作は単一の文字列として検索され(「A | B」は文字通り存在する必要があります)、 RegexMatch ORステートメントが必要な場合は、演算を使用する必要があります。

次のセクションでは、ActiveDiscoveryフィルターのいくつかの一般的な使用例に焦点を当てました。

ユースケース:監視からダウンインターフェイスを除外する

多くの場合、お客様はインターフェースの監視に関心がありません。 したがって、ダウンインターフェイスを除外するために、インターフェイスを監視するデータソースに次のフィルタを追加できます。

ダウンインターフェイスを無視するために使用されるサンプルフィルター

SNMPを介してインターフェイスのテーブルをたどると、検出された各インターフェイスのインターフェイスステータスがOIDで照会されます。 このフィルタが設定されている場合、インターフェイスがフィルタ基準を満たし、モニタリングに追加されるためには、そのステータスが「1」である必要があります。 インターフェイスがダウンしているかテスト中である場合、それはモニタリングに追加されないため、非アクティブなインターフェイスでリソースツリーが乱雑になることはありません。 また、Active Discoveryは定期的に実行されるため、後でインターフェイスが起動すると、フィルターを通過して監視に入ります。

ユースケース:さまざまなタイプのインスタンスにさまざまなデータポイントしきい値を割り当てる

自動検出フィルターを使用して、さまざまなタイプのインスタンスにさまざまなデータポイントしきい値を適用する目的でインスタンスを除外できます。 たとえば、スイッチポートの説明で一貫して「アップリンク」とラベル付けされているアップリンクポートと、ラベルが付けられていないエッジポートを備えたCiscoスイッチがあるとします。 あなたは主にアップリンクポートに関連するアラートに関心がありますが、それでもエッジポートのいくつかの側面を監視することに関心があります。

これを実現するには、LogicMonitorのすぐに使用できるさまざまな側面(フィルターを含む)のクローンを作成して変更する必要があります。 インターフェイス(64ビット)- 情報元。 最終的には、データソースのXNUMXつのバージョンが作成されます。XNUMXつはCiscoデバイスにのみ適用され、アップリンクポートのみを監視します。 Ciscoデバイスにのみ適用され、アップリンク以外のすべてを監視するもの。 そして、Ciscoデバイスを除くすべてに適用されるもの。 次の一連の手順は、このユースケースを実現するために従う必要のあるプロセスの概要を示しています。

  1. クローン インターフェイス(64ビット)- Ciscoアップリンクポートにのみ適用される新しいデータソースを作成するためのデータソース。 複製されたデータソースにわかりやすい名前を付けます(例:「インターフェイス(64ビット)Ciscoアップリンク」)。 データソースのクローン作成の詳細については、を参照してください。 LogicModuleのクローン作成.
  2. 更新する に適用されます 複製されたデータソースのフィールド isCisco() そのため、Ciscoデバイスにのみ適用されます。
  3. インスタンスの監視をアップリンクポートに制限するActiveDiscoveryフィルターを追加します。


    このフィルターは、インターフェースの説明(OID 1.3.6.1.2.1.31.1.1.1.18)に「アップリンク」が存在することを前提としていますが、これと同じ制限を実現する方法は他にもたくさんあります。

  4. アップリンクポートのみを監視するデータソースができたので、非アップリンクを監視するデータソースを作成します。 これをする:
    • 作成した新しいデータソースのクローンを作成します。
    • フィルタを逆にします(つまり、「Contain」演算子の代わりに「NotContain」演算子を使用します)。
  5. StatusおよびStatusFlapデータポイントの静的しきい値を削除して、アップリンクされていないCiscoギアのアラートを減らします。 静的データポイントしきい値の更新の詳細については、を参照してください。 データポイントの静的しきい値の調整.
  6. 元のデータソースがCiscoインターフェイスを監視しないようにするには、 に適用されます 〜へのフィールド hasCategory(“ snmp”)&&!isWindows()&&!isCisco()。 これにより、WindowsデバイスとCi​​scoデバイスを除く、SNMPをサポートするすべてのデバイスにデータソースが適用されます。

ユースケース:インスタンスレベルのプロパティによるフィルタリング

インスタンスレベルのプロパティをフィルタとして使用して、インスタンスを監視する必要がある(またはしない)インスタンスを決定することもできます。 これらのプロパティは、アクティブディスカバリー中に作成および割り当てられます。

たとえば、LogicMonitorのすぐに使える VMware_vSphere_VM スナップショット DataSourceは、埋め込まれたGroovyスクリプトを介して自動検出を実行します。 次に示すように、このスクリプトは、結果のインスタンスに多数のプロパティを割り当てます。これらのプロパティのXNUMXつは次のとおりです。 auto.resource_pool、仮想マシンのリソースプールの名前をキャプチャします。

インスタンスレベルのプロパティを使用したフィルタリング

特定のプール(アラートを必要としないラボまたはテスト環境のプールなど)からインスタンスを除外する場合は、このインスタンスプロパティに基づいてフィルターを作成できます。


このフィルターは、「LAB」という名前のリソースプールから仮想マシンを除外します。

インスタンスレベルのプロパティの詳細については、を参照してください。 リソースとインスタンスのプロパティ.

ユースケース:SNMPフィルタリングのトラブルシューティング

Active Discoveryフィルタは、インスタンスを期待しているが、インスタンスが表示されていない顧客に混乱をもたらす場合があります。 たとえば、すぐに使用できる NetAppSnapVol- DataSourceは、次に示すデフォルトのフィルターを備えています。

一般的なトラブルシューティングのシナリオは、NetAppスナップショットボリュームがXNUMXつだけ表示されるが、それ以上が予想される場合です。 次に示すように、データソース定義で設定されたSNMP OIDを使用して、手動ウォークを実行し、ボリュームインスタンスの完全なリストを取得できます。

$ !snmpwalk SOMEHOST .1.3.6.1.4.1.789.1.5.4.1.2
Walking OID .1.3.6.1.4.1.789.1.5.4.1.2 from host=SOMEHOST, version=v2c, port=161, timeout=3 seconds:
1 => aggr2
10 => /vol/cache1img3/.snapshot
11 => /vol/cache1img4/
12 => /vol/cache1img4/.snapshot
13 => /vol/cache1img5/
14 => /vol/cache1img5/.snapshot
15 => /vol/cache1img6/
16 => /vol/cache1img6/.snapshot
17 => /vol/cache1img7/
18 => /vol/cache1img7/.snapshot
19 => /vol/cache1img8/
2 => aggr2/.snapshot
20 => /vol/cache1img8/.snapshot
21 => /vol/cachepreprod/
22 => /vol/cachepreprod/.snapshot
23 => /vol/cache1imgtest/
24 => /vol/cache1imgtest/.snapshot
3 => /vol/new_root/
4 => /vol/new_root/.snapshot
5 => /vol/cache1img1/
6 => /vol/cache1img1/.snapshot
7 => /vol/cache1img2/
8 => /vol/cache1img2/.snapshot
9 => /vol/cache1img3/

ここには、実際に発見の可能性のあるインスタンスが複数あります。 ただし、1.3.6.1.4.1.789.1.5.4.1.15番目のデフォルトフィルターはボリュームサイズをチェックし、OID .XNUMXからゼロサイズを報告しないものだけを監視に入れます。これが通常、予想されるすべてのボリュームインスタンスが存在しない理由です。 。

記事上で