SNMPが機能しているアクティブディスカバリのトラブルシューティング

同じプロトコルを使用する他のすべてのデータソースが正常に機能しているように見える場合、特定のデータソースがデバイスに適用されていないことに気付くことがあります。 これが発生する理由には多くの原因が考えられますが、最初に最も基本的な原因から始めて、徐々により集中的なチェックに進むことが理想的です。 

この例では、SNMP関連のすべてのデータソースを検出したデバイスがありましたが、インターフェイスデータソースがホストに表示されていませんでした。 同じプロトコルを使用する他のデータソースが正常に機能しているため、アクセス許可やプロトコルの問題ではないようです。 

データソースがホストに関連付けられていることを確認します

これを確認するには、データソースに移動し、ホストが問題のデータソースに関連付けられているかどうかを確認します。 [設定] / [LogicModules] / [データソース]に移動し、確認するデータソースを検索します。 データソースをクリックすると、右上隅に「詳細」というボックスが表示されます。それをクリックして、「関連付けられたデバイスを表示」をクリックします。

ターゲットデバイスが関連付けリストに表示されていることを確認します。

ホストでActiveDiscoveryを手動で実行してみてください。 これを行うには、デバイスの[管理]ボタンの横にある青い矢印をクリックし、[アクティブディスカバリーの実行]を選択します。 

Active Discoveryを手動で実行した後、約30秒後にページを更新すると、データソースがインスタンスとともに表示されることが表示されます(それが実際に問題であった場合)。 そうでない場合は、さらに調査に進むことができます。 

アクティブディスカバリタイムアウト

私たちは行くことができます コレクターデバッグウィンドウ 検出タスクの詳細を参照してください。 デバッグコンソールに入ったら、このホストで現在実行中のActiveDiscoveryタスクを確認します。 このコレクターに他のデバイスがある場合は、問題のデバイスのみを除外することで結果を最小限に抑えることができます。

結果から、追跡しようとしているSNMP64_if-データソースを検索でき、ActiveDiscoveryタスクがタイムアウトしていることがわかります。

ここから、通常、デバイスがその特定のクエリへの応答に通常よりも時間がかかる可能性があるかどうかを確認します。そのため、この特定のデータソースはタイムアウトになり、インスタンスを検出しません。 この例では、SNMP64_if-データソースでインスタンスを検出するために使用されるOIDを使用し、クエリを実行してタイムアウトをテストします。

実行する最初のクエリは、デフォルトのタイムアウト値(3秒)を使用して、ADOIDのデバイスに対してsnmpwalkを実行する応答を取得できるかどうかを確認することです。 以下の例では、元のADタスクで説明したように、そのOIDをウォークするとタイムアウトが発生することがわかります。 

タイムアウトを手動でもう少し長くして、結果が返されるかどうかを確認できます。 ここでは、デバイスが応答するのに十分な時間を確保するために、30秒に延長されました。 

問題がデバイスからの通常よりも長い応答に関連している可能性があると思われる場合は、 その後、コレクター構成ファイルを調整できます コレクターが特定のプロトコルの応答をもう少し待つことができるようにします。 待機時間を長く設定しすぎると、コレクターのパフォーマンスに影響を及ぼし、タスクのバックアップを開始し、最終的にタスクが失敗する可能性があるため、これらの設定を調整するときは非常に慎重に行ってください。 まず、タイムアウトタイムアウト時間を5秒から10秒に倍増し、保存してから、結果をテストします。 

以前、インスタンスが大量にあるクエリでの応答のタイムアウトに関連するAD障害が発生しました。 ジュニパーネットワークスのデバイスは、インターフェイスが非常に多いことで有名であり、SNMPクエリへの応答に少し時間がかかります。 過去に、上記のようにADのSNMPタイムアウトを調整し、大量のインスタンスを検出できるようにする問題を解決しました。

データソースフィルターを確認する

フィルタがインスタンスが検出されない原因である場合があります。これは、フィルタ基準自体が原因であるか、前のセクションで説明したタイムアウトに関連している可能性があります。 SNMPフィルターでは、通常、OIDをチェックし、応答に基づいてフィルター処理します。 トラブルシューティング中に、インスタンスの検出に使用されたOIDが完全に正常に返される場合がありますが、フィルターで使用されたOIDのXNUMXつがタイムアウトし、すべてのActive Discoveryが失敗し、インスタンスが検出されません。 フィルタが問題を引き起こしているかどうかを判断しようとするとき、問題に取り組むために取ることができるいくつかの異なる方法があります。 

方法1-クローンを作成して削除する

データソースのクローンを作成し、すべてのフィルターを削除し、トラブルシューティングの対象となるホストに適用してからデータソースを保存することで、フィルターの問題であるかどうかを簡単に除外できます。 複製されたデータソースにフィルターがない状態でインスタンスがすぐに検出された場合は、元のデータソースの個々のフィルターを調べて、障害の原因となっているフィルターを特定することができます。

これを行うには、デバッグウィンドウの値を確認します。 この例では、データソース内の各フィルターのOIDを実行したことがわかります。
除去のプロセスに基づいて、このシナリオではXNUMXつのインスタンスのみを検出する必要があります。 

方法2–!adetailコマンドを使用してActiveDiscoveryタスクの詳細を確認します

問題の原因としてフィルターをすばやく特定し、フィルターを処理して逆方向に作業できるクローンと削除の方法ではなく、アクティブ検出タスクの詳細を確認することもできます。 

フィルタがインスタンスが検出されない原因であるという良い兆候は、デバッグコマンドウィンドウにアクティブな検出タスクが表示され、タスクが失敗したとは言わなかったが、実際に完了したことです。 完了したがインスタンスが表示されていない場合は、Active Discoveryに使用されたOIDに基づいてインスタンスが見つかったことを意味しますが、データソースに設定されたフィルターを処理したときに、基準を満たしていないため、インスタンスは表示されませんでした。端末。

詳細については、taskidおよび!adetailコマンドを使用してください。
 

このコマンドを実行すると、次の出力が表示されます。これは、検出されたインスタンス、処理されていたフィルター、およびプロセスを通過したインスタンスの最終結果を示しています。 この例では、インスタンス名に「failtest」という単語が含まれるインターフェースを探すフィルターを作成しました。 これらのインスタンスには明らかにそれがなかったため、インスタンスは検出されませんでした。 これを解決するには、フィルターを削除します。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET