コレクターのパフォーマンスとチューニング
最終更新日: 05 年 2025 月 XNUMX 日コレクターのリソース消費 (CPU とメモリの使用率) とコレクターのパフォーマンスは密接に関連しています。コレクターのチューニングには、コレクターの構成を調整したり、ワークロードを再配分してリソースを効率的に監視し、データを収集することが含まれます。コレクターのチューニングは、WMI、SNMP などのデータ収集タスクに対して行われます。単一のコレクション タイプのデータ ソースにデータ ギャップがある場合、またはデータが報告されていない場合は、コレクターのチューニングが行われます。
コレクターのチューニングが必要なシナリオ
コレクターはほとんどの環境で適切に動作するように構成されていますが、次のシナリオでは調整が必要になる場合があります。
- コレクターの過負荷
- 応答しないデバイス
- データ収集ができない
コレクターの過負荷
コレクターの過負荷には、次のような一般的な指標が関係します。
- コレクターを監視用にセットアップした後、コレクターデータ収集タスクデータソースは、コレクターがタスクをスケジュールできないことを警告します。これは、データがデータソーススケジュールに従って収集されていないために発生し、グラフにギャップが生じることもあります。このような場合、コレクターのワークロードを調整する必要があります。詳細については、 コレクターの監視.
- タスク キューに要素が存在する場合、コレクターはタスクのスケジュールを待機する必要があるものの、指定された時間枠内にタスクを完了できることを示します。これは、コレクターが構成された容量に近づいており、調整が必要であることを示しています。
コレクターオーバーロードの例
コレクター データソースを見ると、明らかにコレクターが過負荷になっていることがわかります。スケジュールできないタスクが多数あり、タスク キューが非常に高くなっています。
- キュー内のタスク
- 利用できないスレッド スケジュール タスク
- 実行されたタスク
チューニング後 (1400 時間後)、成功したタスクの数が増加し、使用できないスレッド スケジューリング タスクの数とタスク キューが減少したことを確認できます。
予防策として、すべてのデバイスのデータ収集タスク データソースのすべてのインスタンスについて、データポイント UnavailableScheduleTaskRate 別に上位 10 個のコレクターを表示するコレクター ダッシュボードとカスタム グラフ、および TasksCountInQueue 別に上位 10 個のコレクターを表示する別のグラフを作成できます。各コレクターにはこれらのデータソースのインスタンスが多数あることを考慮すると (収集方法ごとに XNUMX つ)、カスタム グラフのインスタンス制限を超えないように、収集方法を snmp や jmx などのインスタンスとして指定する必要がある場合があります。または、インスタンスを星印 (*) に設定して、XNUMX つのグラフですべての方法を表示することもできます。
応答しないデバイス
応答しないデバイスが原因でコレクターのパフォーマンスが低下するシナリオは次のとおりです。
応答しないデバイスによるコレクターの速度低下
コレクターは、一部のデバイスが応答しなくなると、これまで監視していた同じデバイスを処理できなくなることがよくあります。たとえば、コレクターはキューイングなしで 100 台のデバイスを監視しますが、その後タスク キューが発生し始めたり、タスクをスケジュールできなくなったりします。これは、コレクターが一部のデバイスからデータを収集できなくなったために発生することがあります。コレクターがこれらすべてのデバイスと JMX 経由で通信し、各デバイスが通常 200 ミリ秒以内に JMX クエリに応答していた場合、すべてのデバイスを簡単に循環処理できます。ただし、JMX 資格情報が 10 台のホストで一致しなくなった場合、これらのホストは LogicMonitor クエリに応答しません。コレクターは、構成された JMX がタイムアウトするまでスレッドを開いたままにします。これで、複数のスレッドを開いたままにして、応答を待機するようになります。
コレクタークエリで応答しないデバイス
デバイスがコレクター クエリに応答しない理由は、デバイスの資格情報が変更された、デバイスがオフラインである、LogicMonitor の資格情報が正しく設定されていないなど、いくつか考えられます。プロトコルがデバイスに応答しないというアラートから理由を見つけることができます。これらの問題を解決してデバイスの監視を再開するには、新しい資格情報を設定し、デバイスがオンラインであることを確認するか、LogicMonitor の資格情報を正しく設定します。
時々、デバイスがコレクタークエリに応答しない理由が分からないことがあります。そのような状況では、コレクターデバッグコマンドを実行して、問題がコレクターによってスケジュールされたタスクにあるかどうかを確認できます。コマンドを実行すると、 !tlist c=METHODここで、method は問題のデータ収集方法 (jmx、snmp、WMI など) です。コレクターがスケジュールした、選択した方法のすべてのタスクのリストが表示されます。
タイムアウトまたは応答なしが原因で複数のタスクが失敗する場合は、これらのタスクが、そのプロトコルのタイムアウト期間中、スレッドをビジー状態にしていることを示します。この状況では、スレッドが長時間ブロックされないように、構成されたタイムアウトを短縮する必要があります。JMX タイムアウトが 30 秒で、コンピューターが応答するのに非常に長い時間である場合は、5 秒 (現在のデフォルト) に設定できます。タイムアウトを設定するときは、変更されたタイムアウトが環境に適していることを確認してください。
プロトコルのタイムアウトを変更するには、次の手順に従います。
- コレクター構成ウィンドウから、コレクター構成を手動で編集します。
- 更新するプロトコルのタイムアウトを変更するには、collector.*.timeoutパラメータを編集します。たとえば、次のように変更します。
collector.jmx.timeout=30〜へcollector.jmx.timeout=5
ご注意: JMX タイムアウトを 5 秒に設定するのが適切である場合もありますが、Web ページのレンダリングにはさらに時間がかかるため、Web ページ コレクターには 30 秒が必要です。Web ページの場合、タイムアウトを短い期間に設定すると、監視に悪影響を及ぼします。
タイムアウト期間を短縮することに加えて、スレッドの数を増やす必要がある場合もあります。
データを収集できません
コレクターがデータを収集できない場合は、収集方法のスレッド数を増やす必要がある場合があります。これにより、コレクターはより多くのタスクを同時に実行できるようになります (特に、一部のスレッドがタイムアウトを待機している場合)。ただし、コレクターの CPU 使用率は増加します。
コレクション メソッドのスレッドを増やすには、次の手順に従います。
- コレクター構成ウィンドウから、コレクター構成を手動で編集します。
- 更新するプロトコルのスレッドプール割り当てを増やすには、collector.*.threadpoolパラメータを編集します。たとえば、
collector.jmx.threadpool=50〜へcollector.jmx.threadpool=150.
推奨事項： スレッドプールの設定は徐々に増やすことができます。最初は現在の設定を 2 倍にして、その影響を観察します。コレクターの CPU 使用率とヒープ使用率の変化に注意する必要があります。スレッド数が増えると、CPU の消費量が増え、JVM ヒープにさらに負荷がかかります。ヒープ使用量 (コレクター データソース コレクター JVM ステータスの下に表示されます) が制限に近づいている場合は、ヒープ使用量の制限を増やすことができます。
スレッド数とヒープ制限を増やしても、コレクターがデータを収集できない場合、または CPU 容量に達している場合は、別のコレクターを追加して、コレクター間でワークロードを分割することをお勧めします。
コレクターのチューニング
コレクターが遭遇する問題の性質に基づいて、コレクターを調整できます。コレクターの調整には、次の対策が含まれます。
- コレクターのサイズに応じてコレクター構成を変更できます。詳細については、 コレクター構成ファイルの編集.
- コレクターを実行しているサーバーに十分なメモリがあるかどうかを確認する必要があります。必要に応じて、メモリを増やす必要があります。
- コレクターのサイズを大きくします。たとえば、小さいサイズのコレクターは 2 GB のメモリしか使用しませんが、大きいサイズにアップグレードすると、より多くの作業を実行できます。詳細については、 コレクター容量.