Discovery のパフォーマンス、キャンセル、およびタイムアウトのトラブルシューティングIssue 検出スケジュールには、[最大実行時間] フィールドがあります。「最大実行時間」に達すると、検出ステータスはキャンセルされます。 検出スケジュールがキャンセルされたり、動作が予想よりも遅くなったりする理由は多数あります。検出スケジュールがキャンセルされて終了するいくつかの理由は次のとおりです。 MID Server での処理中に出力プローブが「ハングアップ」する出力プローブが準備完了ステータスのままになる目的の時間内に ecc キューレコードを処理するための十分な MID Server リソースがありません入力は準備完了ステータスのまま 検出される CI の数が増えると、検出スケジュールの完了にかかる時間も長くなります。検出スケジュールで検出される CI の数が増加した場合は、MID Server の数、MID Server スレッド、MID Server メモリの数などの検出スケジュールに割り当てられたリソースや最大実行時間を増やす必要があります。 MID Server 構成 以下のドキュメントページには、MID Server リソースを増やし、スレッドとメモリ使用率を設定するためのガイドラインが記載されています MID Server の JVM メモリサイズを設定するMID Server スレッド使用を設定する トラブルシューティング 遅い検出 検出タイムラインを表示 [検出タイムラインを表示] ボタンは、小規模な検出のタイムラインを確認するのに役立ちます。デフォルトの制限は 300 件の ecc_queue レコードです。この制限は、glide.discovery.timeline.max_entries で制御できます。この制限は 300 に維持し、このタイムラインは小規模な検出のトラブルシューティングにのみ使用することをお勧めします。 検出パフォーマンス測定基準 Madrid 以降、個々のプローブ、ビルドバージョン、検出ステータス、およびターゲット IP アドレスごとにパフォーマンス測定基準が収集されます。 個人 各プローブとセンサーのプローブとセンサーの処理時間を表示します。入力が SensorProcessor によって処理された際に記録されます。値 (true/false) を持つプロパティ「glide.discovery.perf.metrics.enable_collection」によって制御されます。検出パフォーマンス測定基準を表示するには、次のいずれかを実行します。 [検出] > [検出パフォーマンス測定基準] > [プローブ/センサー(個人)] に移動します。[検出ステータス] フォームに関連リスト [プローブとセンサーの測定基準 (個人)] を追加します。 個々の測定基準は、入力が返されて処理されたプローブについてのみ記録されます。測定基準は検出ステータスでフィルタリングし、「プローブ処理時間」または「センサー処理時間」で並べ替えて、実行時間が最も長いものを見つけることができます。例： ビルド ビルドバージョンごとのプローブ測定基準を表示します。スケジュール設定済みジョブ「Aggregate Discovery Probe And Sensor Metrics By Build」を介して毎日収集され、値 (true/false) を持つプロパティ「glide.discovery.perf.metrics.rollup_by_build」によって制御されます。 検出ステータス ステータスごとのプローブ測定基準を表示します。検出が完了したときにスクリプトアクションによって収集され、値 (true/false) を持つプロパティ「glide.discovery.perf.metrics.rollup_by_status」によって制御されます。 ターゲット IP アドレス ターゲット IP アドレスごとのプローブの集計時間を表示します。検出が完了したときにスクリプトアクションによって収集され、値 (true/false) を持つプロパティ「glide.discovery.perf.metrics.rollup_by_target」によって制御されます注意： ターゲット別の測定基準は、検出を完了しなかったデバイスについては記録されません。したがって、測定基準は、どのデバイスとデバイスタイプが最も時間がかかっているかを判断するために検出を分析するのに役立ちますが、検出がキャンセルされた原因となったデバイスを特定するのには役立ちません。検出が最大実行時間のしきい値を超える要因となったデバイスは完了しておらず、パフォーマンス情報が収集されないためです。 上記の測定基準の組み合わせを使用して、検出のパフォーマンスに最も影響を与えるプローブまたは IP を特定できます。平均は、データセットが十分に大きい場合にのみ統計的に有意になることに注意してください。小さいデータセットには外れ値があり、平均が大きく歪む可能性があります。 詳細については、Discovery のパフォーマンス測定基準を参照してください。 キャンセルされた検出 [ECC キュー] 関連リストで、[処理済み] が空のレコードを確認します。 検出がキャンセルされると、処理されていないすべての ecc_queue レコードのステータスが [処理済み] に変更されます。ただし、プローブ/センサーの処理が完了した時間である [処理済み] フィールドは空のままです。したがって、処理済みが (空) のレコードを見つけることで、検出がキャンセルされたときにまだ実行されていたプローブを特定できます。 次のスクリーンショットでは、[更新日時] フィールドについて、検出ジョブの ECC キューレコードが新しいものから古いものの順に並べられています。デフォルトでは、[更新日時] フィールドは [ECC キュー] 関連リストに表示されません。[更新日時] 列を追加すると、プローブが完了するまでにかかった時間を測定できます。 (更新日時 - 処理日時 = 出力プローブが MID Server で費やした時間、スレッドがプローブを実行可能になるまで内部キューに待機した時間とプローブの実行時間を含みます。) 注意：強調表示された ECC キューレコードは、上記の検出例がキャンセルされる 1 時間前に作成されましたが、まだ処理されていません。 これは、このプローブが上記の検出がキャンセルされた原因であることを示しています。上記の例は、1 つのプローブのみが処理されなかったため、簡単に原因を特定できるという単純なケースのシナリオです。ただし、場合によっては、複数のプローブがハングアップし、検出のタイムアウトの原因となることがあります。このような場合は、キャンセルされた検出の ECC キューを分析し、「トピック」または「プローブ名」が同じである処理済み (空) の多くのプローブなどのパターンを探すことが重要です。一般に、検出がキャンセルされた原因となった ECC キューレコードを見つけるには、[作成日時] フィールドと [更新日時] フィールドの間のギャップが大きいレコードを探します。 キャンセルされた検出の ECC キューを分析する場合は、キューを出力と入力に分割します。 出力は MID Server によって処理されます。出力がハングアップすると、MID Server の問題が示される入力はインスタンスによって処理されます。入力がハングアップすると、インスタンス側の問題が示される 検出がキャンセルされた原因となっているプローブ/IP が特定されたら、プローブが完全に処理されない理由をトラブルシューティングするために、新しい調査が必要になります。IP アドレスを例外として検出スケジュールに追加して、プローブのソリューションが見つかるまで検出が正常に完了するようにすることができます。 [デバイス] 関連リストで、[スキャンステータス] が [完了] でないデバイスを確認します。 検出がキャンセルされても、[デバイス] 関連リストは更新されません。したがって、プローブが完了しなかったデバイスの [スキャンステータス] は [完了] になりません。次の画像は、検出がキャンセルされたときにまだスキャンされているデバイスを示しています。この関連リストから、デバイスの IP アドレスであるソースを収集し、完了しなかったプローブを [ECC キュー] 関連リストで探すことができます。 注：上のスクリーンショットでは、「ソース」と「CMDB CI」の両方がクリアされています。Related Links関連するトピック： Discovery Cancellation Process Overview