LogicMonitor + Catchpoint: 自律型ITの新時代へ

さらに詳しく

アクティブ検出は、LogicMonitor がマルチインスタンス LogicModule のインスタンスを検出して識別するために使用するプロセスです。アクティブ検出の結果は、LogicMonitor が特定の種類のデータを収集するために使用できる 1 つ以上のインスタンスの識別です。 

インスタンスは、リソース ツリー内の親 LogicModule の下に編成されます。 

LogicModule リソース ツリー ページ

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

アクティブ検出が有効になっているデータソースには、アクティブ検出の実行間隔を定義する検出スケジュールがあります。この検出スケジュールはデータソース定義から設定され、データソースごとに異なります。詳細については、 ActiveDiscoveryの構成.

たとえば、システム内のファンや CPU の数など、あまり頻繁に変更されないオブジェクトには、1 日に 1 回の収集スケジュールが割り当てられます。ただし、NetApp ディスク アレイ上のボリュームのように頻繁に変更されるオブジェクトには、1 時間に数回の収集スケジュールが割り当てられます。

自動検出は、データソースで定義された検出スケジュールに従って実行されるだけでなく、次の場合にも実行されます。 

  • リソース (またはデータソース) が監視に追加されます。
  • リソースまたはデータソースのプロパティ/構成が変更されます。
  • これはリソースツリーから手動で開始されます。アクティブ検出を手動で実行する機能は、リソースに新しいオブジェクトを追加し、スケジュールされたアクティブ検出の実行を待たずに LogicMonitor がすぐにそのオブジェクトを監視対象として取得するようにしたい場合に便利です。詳細については、 インスタンスの追加.

注意: 特定のリソースまたはリソースのグループに対してデータソース監視を無効にすると、そのデータソースのアクティブ検出も無効になります。つまり、影響を受けるリソースのインスタンスは検出、更新、または削除されません。詳細については、 データソースまたはインスタンスの監視を無効にする.

アクティブ検出中に取得される情報

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

  • インスタンス名—リソース ツリーに表示されるインスタンスの説明的な名前。
  • インスタンスID— インスタンスの ID。デバイスにデータを照会するときにこのインスタンスを識別するための変数として使用されます。たとえば、SNMP OID ツリーの変数部分や、ストレージ システム内のボリューム ID などです。 

注意: ID は常に一意である必要があります。

  • インスタンスの説明—インスタンスのオプションの説明。これは、リソースツリーにインスタンス名とともに表示されます。
  • インスタンスプロパティ—インスタンスに関する静的データを提供するキーと値のペアのオプション セット。これらはリソース プロパティに似ていますが、インスタンスごとに収集されます。収集されたインスタンス プロパティは保存され (UI に表示されます)、インスタンスをグループ化するためのキーとして使用したり、複雑なデータポイント計算の一部として使用したりできます。次のプロパティは、一般的にインスタンス プロパティとして収集されます。
    • スイッチシャーシまたはストレージシステムのドライブで検出された各FRUのシリアル番号。
    • ハイパーバイザーによってホストされる各 VM のメタデータ (CPU 数、メモリ割り当て、仮想 NIC 数、ゲスト OS など)。
    • 各ネットワークインターフェイスのポート速度。

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

アクティブディスカバリーでインスタンスプロパティを収集するだけでなく、インスタンスに手動でプロパティを割り当てることもできます。詳細については、 リソースとインスタンスのプロパティ.

ActiveDiscoveryの構成

アクティブディスカバリは、一度に1つのデータソースに対して設定されます。したがって、データソース定義から設定されます。データソース定義は、監視に関連する多くの設定を制御します。詳細については、 データソースの構成

DataSource のアクティブ検出を構成するには、次の手順を実行します。 

  1. MFAデバイスに移動する  私のモジュールツールボックス。
  2. ドロップダウンリストから 情報元。
  3. 選択する  編集 アクティブ検出オプションを展開します。
  4. トグル 有効にする アクティブディスカバリー。 
    有効にすると、LogicMonitor は DataSource のインスタンスとそれらが適用されるリソースを自動的に検出します。 

注意: アクティブ検出を構成するには、マルチインスタンス オプションをオンにする必要があります。以前に保存した LogicModule のアクティブ検出を無効にすることはできません。

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

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

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

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

If インスタンスを自動的に削除する オプションがオンになっている場合、将来のアクティブ検出の反復でインスタンスがデバイス上に存在しないことが報告されると、LogicMonitor はインスタンスを自動的に監視から削除します。

推奨事項: インスタンスが存在しない場合でも、そのインスタンスに関するアラートを受信したい場合は、[インスタンスを自動的に削除] をオフに切り替えます。たとえば、Active Discovery が、リスニング中の TCP ポートを検出してサービスを監視する必要があることを検出した場合は、このオプションをオンにしない方がよいでしょう。ポートが応答を停止すると、Active Discovery はインスタンスが存在しないと報告し、監視から削除して、そのインスタンスに関するアラートを受信しなくなります。

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

  • すぐに削除—インスタンスが存在しないと判断されると、インスタンス (およびそのすべての監視履歴) は LogicMonitor から直ちに削除されます。
  • 30日後に削除—インスタンスは存在しないと判断されるとすぐにリソース ツリーから消えますが、その監視履歴は LogicMonitor に 30 日間残り、その後削除されます。この 30 日間の期間内にインスタンスが再検出された場合、以前の監視履歴は再検出時に再度関連付けられます。この猶予期間は、故障したネットワーク カードの交換など、新しいカードがアクティブになったときに古い履歴を表示したい場合に役立ちます。
    • インスタンスの保持—削除されたインスタンスがLogicMonitorに表示される期間を指定します。その後、インスタンスは完全に削除されるまでの期間です。削除済みとしてマークされたインスタンスは、指定された日数後に完全に削除されます。0は即時削除、1は2日後、XNUMXはXNUMX日後に削除、というように続きます。このオプションは、 30日後に削除 オプションを選択します。 

注意: 現在、これは次のデータソースに対してのみ有効になっています。

  • BGP
  • Cisco_EIGRP_ピア
  • Cisco_ISIS_Neighbors
  • ISIS_隣人
  • OSPF_ネイバー。

推奨事項: 新しいインスタンスが古いインスタンスと関連していない場合は、履歴を保持する必要はありません。

発見スケジュール

アクティブ検出は、15 分ごと、XNUMX 時間ごと、または XNUMX 日に XNUMX 回のスケジュールで実行するように構成できます。または、データソースがデバイスに最初に適用されたとき、またはデータソース (またはそれが適用されるデバイス) が何らかの方法で更新されたときにのみ実行するように構成することもできます。

グループ方式

その グループ方式 検出時にインスタンスがどのように編成されるかを決定します。 

グループ化の方法には次の 3 つがあります。

  • マニュアル - 検出後にインスタンスを手動でグループに整理するか、永続的にグループ化しないままにします。
  • 正規表現—このメソッドは 3 つのパラメータをサポートします。 
  • インスタンスレベルのプロパティ—その ILP の一意の値ごとにインスタンス グループが自動的に作成されます。 

詳細については、 インスタンスグループ

コレクション引数

コレクション引数フィールドは、選択したアクティブ検出方法に基づいて変化します。 

発見方法

その 発見方法 フィールドは、アクティブ検出がインスタンスを見つけるために使用する方法を定義します。LogicMonitor のアクティブ検出プロセスは、デバイスまたはシステムに監視可能なオブジェクトについて照会するためのさまざまな方法をサポートしています。これには次のものが含まれます。

  • コレクタ-コレクターをインスタンスとして検出します。
  • HTTP—HTTP / HTTPSURLを照会します。
  • JDBC—データベースクエリを起動します。
  • JMX—特定のJavaManagementExtensionsパスを照会します。
  • パフォーマンスモニター—Windows Perfmon クラスを照会します。
  • ポート-特定のTCPポートに接続します。
  • スクリプト-スクリプトの出力を使用します。
  • SNMP—SNMPクエリを起動します。
  • WMI—WindowsWMIクラスを照会します。
  • さまざまなAPI—一部のシステムおよびアプリケーションでは、LogicMonitor は、Citrix XenServer API、MongoDB API、NetApp API、VMware ESX API などの独自の API を直接クエリすることでアクティブ検出をサポートします。
  • さまざまなパブリッククラウドリソース—パブリック クラウド リソースの場合、LogicMonitor は、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure でホストされているものを含む独自のクラウド システムを直接クエリすることで、アクティブ検出をサポートします。

さまざまな検出方法に必要な固有の引数の設定の詳細については、製品ドキュメントの個別のサポート記事を参照してください。 

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

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

フィルターを使用すると、アクティブ検出を通じて監視に追加されるインスタンスを制限できます。 1 つ以上のフィルターが設定されている場合、インスタンスが検出されるには、フィルターの条件に一致する必要があります。

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

フィルターの設定

  1. MFAデバイスに移動する  私のモジュールツールボックス。
  2. ドロップダウンリストから 情報元。
  3. まず アクティブディスカバリー タブ、次に選択  編集 アクティブ検出オプションを拡張するオプション。
  4. 下にスクロールします フィルター >   edit.
  5. 特定の属性が満たす必要がある条件を指定します。

注意: 属性は、インスタンス レベルのプロパティ、SNMP OID、または WMI クエリ出力で見つかった属性を表すことができます。

フィルターステートメントの構築

いくつかの標準的な操作タイプ、例えば EqualNotEqualLessThanContain、RegexMatch などが利用可能です。

注意: 「OR」ステートメントを検出する必要がある場合は、RegexMatch を使用します。たとえば、「A|B」で文字列内の A または B を検出する必要がある場合は、Contain ではなく RegexMatch を選択してフィルタリングします。

フィルターの使用例

ダウンしているインターフェースを監視から除外する

ダウンしているインターフェースを除外するには、インターフェースを監視する DataSource に次のフィルターを追加できます。

フィールド名フィールド情報
プロパティ名自動インターフェースの動作状態
Operator等しい
up
コメント稼働中のインターフェースを表示する
モジュール フィルター ページ

異なるタイプのインスタンスに異なるデータポイントしきい値を割り当てる

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

これを実現するには、LogicMonitor のすぐに使用できるインターフェイス (64 ビット) - DataSource のさまざまな側面 (フィルターを含む) を複製して変更する必要があります。最終的には、Cisco デバイスにのみ適用されアップリンク ポートのみを監視する DataSource、Cisco デバイスにのみ適用されアップリンク以外のすべてを監視する DataSource、および Cisco デバイス以外のすべてに適用される DataSource の XNUMX つのバージョンが作成されます。

次の一連の手順は、このユースケースを実現するために従う必要があるプロセスの概要を示しています。

  1. Cisco アップリンク ポートにのみ適用される新しいデータ ソースを作成するために、インターフェイス データ ソースを複製します。
    クローンされたデータソースにわかりやすい名前を付けます。詳細については、 LogicModuleのクローン作成.
  2. 更新する に適用されます 複製されたデータソースのフィールド isCisco() そのため、Ciscoデバイスにのみ適用されます。
  3. 追加する アクティブ検出フィルター インスタンスの監視をアップリンク ポートに制限します。
  4. 非アップリンクを監視する新しいデータソースを作成します。これを行うには、次の手順を実行します。
    • 作成した新しいデータソースのクローンを作成します。
    • フィルターを逆にします。たとえば、「Contain」演算子の代わりに「NotContain」演算子を使用します。
  5. ステータスとステータスフラップのデータポイントの静的しきい値を削除して、アップリンク以外のシスコ機器のアラートを減らします。詳細については、 データポイントの静的しきい値の調整.
  6. 元のデータソースがCiscoインターフェイスを監視しないようにするには、 に適用されます 〜へのフィールド hasCategory(“snmp”)&& !isWindows() && !isCisco()。 これにより、WindowsデバイスとCi​​scoデバイスを除く、SNMPをサポートするすべてのデバイスにデータソースが適用されます。

インスタンスレベルのプロパティのフィルタリング

インスタンス レベルのプロパティは、どのインスタンスを監視対象にするか (または監視対象にしないか) を決定するためのフィルターとして使用できます。これらのプロパティは、アクティブ検出中に作成され、割り当てられます。

たとえば、LogicMonitor の VMware_vSphere_VMsnapshots データソースは、埋め込まれた Groovy スクリプトを通じて自動検出を実行します。

このスクリプトは、結果のインスタンスに多数のプロパティを割り当てます。これらのプロパティの1つは auto.resource_pool、仮想マシンのリソースプールの名前をキャプチャします。

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

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

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

インスタンスを期待しているのにそれが表示されない場合には、アクティブ検出フィルターによって混乱が生じる可能性があります。 

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

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

14日間フルアクセス LogicMonitor プラットフォーム