コレクター容量
コレクターが処理できるデータの量は、コレクターの構成とリソースによって異なります。 コレクターのデータ収集の負荷とパフォーマンスを監視して、中断を最小限に抑え、コレクターがダウンしたときに通知することができます。 見る コレクターの監視.
大規模な環境で、コレクターの使用不可タスクレートデータソースでアラートが発生している場合は、コレクターを調整して監視容量を増やす必要がある場合があります。
デバイス容量の制限
次の表は、50秒あたりのリクエスト数（RPS）で測定されたさまざまなサイズのコレクターの容量（2秒あたりのイベント数（EPS）で測定されるSyslogを除く）と、XNUMX個のインスタンスがあると想定する「標準デバイス」の観点から説明しています。 XNUMX分の頻度でチェックされた各プロトコルによって収集されます。 これらの測定値は推定値であり、すべての実稼働環境で正確であるとは限りません。
| 実験概要 | 小さなコレクター | ミディアムコレクター | 大型コレクター | 特大（XL）コレクター | ダブルエクストララージ（XXL）コレクター |
| CPU：1 IntelXeonファミリ システムメモリ：2GiB JVMの最大メモリ：1GiB |
CPU：2 Intel Xeon E5-2680v2 2.8GHz システムメモリ：4GiB JVMの最大メモリ：2GiB |
CPU：4 Intel Xeon E5-2680v2 2.8GHz システムメモリ：8GiB JVMの最大メモリ：4GiB |
CPU：8 システムメモリ：16GiB JVMの最大メモリ：8GiB |
CPU：16 システムメモリ：32GiB JVMの最大メモリ：16GiB |
|
| SNMP v2c | 500RPS （1200の標準デバイス） |
750RPS （1800の標準デバイス） |
1250RPS （3000の標準デバイス） |
1660RPS （4000の標準デバイス） |
1880RPS （4500の標準デバイス） |
| SNMP v3 | 500RPS （1200の標準デバイス） |
666RPS （1600の標準デバイス） |
833RPS （2000の標準デバイス） |
1000RPS （2400の標準デバイス） |
1170RPS （2800の標準デバイス） |
| HTTP | 160RPS （320の標準デバイス） |
735RPS （1400の標準デバイス） |
1260RPS （2400の標準デバイス） |
2000RPS （4500の標準デバイス） |
3740RPS （7500の標準デバイス） |
| WMI | 82RPS （160の標準デバイス） |
620RPS （1200の標準デバイス） |
1033RPS （2000の標準デバイス） |
TBA | TBA |
| 演奏者 | 87RPS （200の標準デバイス） |
173RPS （400の標準デバイス） |
347RPS （800の標準デバイス） |
TBA | TBA |
| JMX | 416RPS （1000の標準デバイス） |
1041RPS （2500の標準デバイス） |
2083RPS （5000の標準デバイス） |
TBA | TBA |
| Syslog | TBD | 500 EPS （イベントサイズを100〜200バイトと想定） |
2500 EPS （イベントサイズを100〜200バイトと想定） |
4000 EPS （イベントサイズを100〜200バイトと想定） |
7000 EPS （イベントサイズを100〜200バイトと想定） |
容量は、監視対象デバイスごとに検出する必要のあるインスタンスの数にも依存します。 たとえば、各デバイスが10,000インスタンスのロードバランサーである場合、コレクターの容量は低くなります。 また、各デバイスが数百のインターフェイスを備えたスイッチである場合、検出によって制限されるため、コレクターの容量が低くなる可能性があります。
ノート:
- CollectorがAmazonEC2インスタンスで実行される場合は、クレジットベースのインスタンスタイプ（T3など）ではなく、固定パフォーマンスインスタンスタイプ（M3やC2など）を使用することをお勧めします。
- Nano Collectorのサイズは、次の表には含まれていません。 これは、NanoCollectorがテスト目的を目的としているためです。 そのため、推奨されるデバイス数の容量は割り当てられていません。
- JDK 11（Collectorバージョン28.400以降の番号のバージョンでサポート）を使用するコレクターでは、同じハードウェア上の以前のJDK 10コレクターよりもメモリとCPUの使用量が約8％多くなります。 将来のバージョンでこれを改善するために取り組んでいます。
VMのコレクターメモリ要件
Collectorのシステムメモリ割り当ての一部は、スタンドアロンスクリプトエンジン（SSE）専用であり、デフォルトで有効になっており、スクリプトデータソース（Groovyスクリプト）の実行に使用されます。
| コレクターサイズ | SSEメモリ要件 |
| 小さい | 0.5GiB |
| ミディアム | 1GiB |
| 大型タッチスクリーン | 2GiB |
| 特大 | 4GiB |
| ダブルエクストララージ | 8GiB |
一般に、SSEは、JVMに割り当てられたメモリ量の半分を必要とします。 メモリ要件は共有されませんが、SSE要件はJVMメモリ要件に追加されます。 コレクターに使用可能なこのメモリーがない場合、SSEは開始されず、「コレクターステータス」ダイアログに「SSEコレクターグループが見つかりません」と表示されます。 コレクターはSSEがなくても機能しますが、GroovyスクリプトはSSEではなくエージェントから実行されます。
コレクターがVMで実行されている場合、OSが空きメモリがあることを示しているため、このセーフガードをオーバーライドできます。 VMのこのバーストメモリ容量は、前述のシステムメモリ要件を超えてメモリ使用量を増やす可能性があります。 これは任意のサイズのコレクターで発生する可能性がありますが、小さなコレクターで発生する可能性がはるかに高くなります。
SSEを無効にし、追加のメモリ使用を防ぐには、コレクターを編集します agent.conf:
- 構成設定が次の場合
groovy.script.runner=sseに変更groovy.script.runner=agent. - 以前の設定が存在しない場合は、次の設定を更新します。
collector.script.asynchronous=false.
詳細については、を参照してください。 コレクター構成ファイルの編集.
NetFlow容量
前の容量表で呼び出されたサンプル環境を使用して、以下は ネットワークトラフィックフロー （NetFlow）/秒。さまざまなサイズのコレクターで監視できます。
Linux 64ビット
| コレクターサイズ | 監視対象デバイスの数 | サポートされているフロー/秒 |
| 小さい | 1 | TBA |
| 5 | TBA | |
| ミディアム | 1 | TBA |
| 5 | TBA | |
| 大型タッチスクリーン | 1 | 113380 |
| 5 | 92740 | |
| XL | 1 | 164870 |
| 5 | 117730 | |
| XXL | 1 | 187870 |
| 5 | 130530 | |
64ビットのWindows
| コレクターサイズ | 監視対象デバイスの数 | サポートされているフロー/秒 |
| 小さい | 1 | TBA |
| 5 | TBA | |
| ミディアム | 1 | TBA |
| 5 | TBA | |
| 大型タッチスクリーン | 1 | 92040 |
| 5 | 72950 | |
| XL | 1 | 120120 |
| 5 | 74890 | |
| XXL | 1 | 120540 |
| 5 | 79420 |
コレクターサイズの調整
LogicMonitor UIからコレクターのサイズを調整できます。特に、 性能調整 インストール後にコレクターの容量を増やします。
From コレクターの管理| サポート| コレクター構成、ドロップダウンメニューからコレクターサイズを選択します。 設定を「保存して再起動」すると、LogicMonitorは、ホストに新しいコレクターサイズをサポートするのに十分なメモリがあることを自動的に確認します。
注意：
- 古いコレクターは、インストール後にパラメーターが変更されていない場合でも、ドロップダウンに現在のサイズを「カスタム（xGiB）」として表示します。 これは、コレクターがインストールされてからサイズの定義が変更されたためです。 コレクターの構成が最新であることを確認する場合は、必要なサイズ（または最初にインストールしたサイズ）を選択し、[保存して再起動]を選択します。
- コレクターのサイズを変更しても、そのサイズに関係のないパラメーターには影響しません。 以下のセクション「構成の詳細」にリストされているパラメーターは、コレクターのサイズの変更によって影響を受ける唯一のパラメーターです。
コレクターの構成パラメーターを手動で変更する場合は、「保存して再起動」を選択した後に有効性チェックを実行して、新しい構成でエラーが発生していないことを確認します。 エラーが検出された場合は、どの行が欠落/重複しているかを表示して、修正できるようにします。
構成の詳細
小さなコレクター
| 設定ファイル | パラメーター | 製品説明 |
| wrapper.conf | wrapper.java.initmemory = 128 | コレクターの最小Javaヒープサイズ（MiB） |
| ラッパー.java.maxmemory = 1024 | コレクターの最大Javaヒープサイズ（MiB） | |
| sbproxy.conf | wmi.stage.threadpool.maxsize = 100 | sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ |
| wmi.connection.threadpool.maxsize = 50 | sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ | |
| agent.conf | sbproxy.connector.capacity = 8192 | コレクターがsbwinproxyおよびsblinuxproxyに並行して送信できる要求の最大数 |
| Discover.workers = 10 | ActiveDiscoveryイテレーションにリソースを割り当てます | |
| autoprops.workers = 10 | APのスレッドプールサイズ | |
| reporter.persistent.queue.consume.rate = 10 | API呼び出しごとに報告されるデータエントリの最大数。 | |
| reporter.persistent.queue.consumer = 10 | バッファからの読み取りとレポートの実行に使用されるスレッド数。 | |
| コレクター.script.threadpool = 100 | スクリプトタスクを実行するための最大スレッド数。 | |
| ウェブサイト.conf | sse.max.spawn.process.count = 3 | 同サイズ |
ミディアムコレクター
| 設定ファイル | パラメーター | 製品説明 |
| wrapper.conf | wrapper.java.initmemory = 512 | コレクターの最小Javaヒープサイズ（MiB） |
| ラッパー.java.maxmemory = 2048 | コレクターの最大Javaヒープサイズ（MiB） | |
| sbproxy.conf | wmi.stage.threadpool.maxsize = 200 | sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ |
| wmi.connection.threadpool.maxsize = 100 | sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ | |
| agent.conf | sbproxy.connector.capacity = 8192 | コレクターがsbwinproxyおよびsblinuxproxyに並行して送信できる要求の最大数 |
| Discover.workers = 40 | ActiveDiscoveryイテレーションにリソースを割り当てます | |
| autoprops.workers = 10 | APのスレッドプールサイズ | |
| reporter.persistent.queue.consume.rate = 12 | API呼び出しごとに報告されるデータエントリの最大数。 | |
| reporter.persistent.queue.consumer = 10 | バッファからの読み取りとレポートの実行に使用されるスレッド数。 | |
| コレクター.script.threadpool = 200 | スクリプトタスクを実行するための最大スレッド数。 | |
| ウェブサイト.conf | sse.max.spawn.process.count = 5 | 同サイズ |
大型コレクター
| 設定ファイル | パラメーター | 製品説明 |
| wrapper.conf | wrapper.java.initmemory = 1024 | コレクターの最小Javaヒープサイズ（MiB） |
| ラッパー.java.maxmemory = 4096 | コレクターの最大Javaヒープサイズ（MiB） | |
| sbproxy.conf | wmi.stage.threadpool.maxsize = 400 | sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ |
| wmi.connection.threadpool.maxsize = 200 | sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ | |
| agent.conf | sbproxy.connector.capacity = 16384 | コレクターがsbwinproxyおよびsblinuxproxyに並行して送信できる要求の最大数 |
| Discover.workers = 80 | ActiveDiscoveryイテレーションにリソースを割り当てます | |
| autoprops.workers = 15 | APのスレッドプールサイズ | |
| reporter.persistent.queue.consume.rate = 12 | API呼び出しごとに報告されるデータエントリの最大数。 | |
| reporter.persistent.queue.consumer = 15 | バッファからの読み取りとレポートの実行に使用されるスレッド数。 | |
| コレクター.script.threadpool = 300 | スクリプトタスクを実行するための最大スレッド数。 | |
| ウェブサイト.conf | sse.max.spawn.process.count = 5 | 同サイズ |
XLコレクター
| 設定ファイル | パラメーター | 製品説明 |
| wrapper.conf | wrapper.java.initmemory = 1024 | コレクターの最小Javaヒープサイズ（MiB） |
| ラッパー.java.maxmemory = 8192 | コレクターの最大Javaヒープサイズ（MiB） | |
| sbproxy.conf | wmi.stage.threadpool.maxsize = 800 | sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ |
| wmi.connection.threadpool.maxsize = 400 | sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ | |
| agent.conf | sbproxy.connector.capacity = 32768 | コレクターがsbwinproxyおよびsblinuxproxyに並行して送信できる要求の最大数 |
| Discover.workers = 160 | ActiveDiscoveryイテレーションにリソースを割り当てます | |
| autoprops.workers = 20 | APのスレッドプールサイズ | |
| reporter.persistent.queue.consume.rate = 15 | API呼び出しごとに報告されるデータエントリの最大数。 | |
| reporter.persistent.queue.consumer = 20 | バッファからの読み取りとレポートの実行に使用されるスレッド数。 | |
| コレクター.script.threadpool = 400 | スクリプトタスクを実行するための最大スレッド数。 | |
| ウェブサイト.conf | sse.max.spawn.process.count = 10 | 同サイズ |
XXLコレクター
| 設定ファイル | パラメーター | 製品説明 |
| wrapper.conf | wrapper.java.initmemory = 2048 | コレクターの最小Javaヒープサイズ（MiB） |
| ラッパー.java.maxmemory = 16384 | コレクターの最大Javaヒープサイズ（MiB） | |
| sbproxy.conf | wmi.stage.threadpool.maxsize = 1600 | sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ |
| wmi.connection.threadpool.maxsize = 800 | sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ | |
| agent.conf | sbproxy.connector.capacity = 65536 | コレクターがsbwinproxyおよびsblinuxproxyに並行して送信できる要求の最大数 |
| Discover.workers = 320 | ActiveDiscoveryイテレーションにリソースを割り当てます | |
| autoprops.workers = 30 | APのスレッドプールサイズ | |
| reporter.persistent.queue.consume.rate = 20 | API呼び出しごとに報告されるデータエントリの最大数。 | |
| reporter.persistent.queue.consumer = 30 | バッファからの読み取りとレポートの実行に使用されるスレッド数。 | |
| コレクター.script.threadpool = 600 | スクリプトタスクを実行するための最大スレッド数。 | |
| ウェブサイト.conf | sse.max.spawn.process.count = 15 | 同サイズ |
最小推奨ディスク容量
コレクターはメモリー内で動作しますが、キャッシュなどの操作には、ホスト上に使用可能なディスク容量が必要です。 必要なストレージの正確な量は、コレクターのサイズ、構成、NetFlowの使用状況、コレクターログの数などの要因によって異なります。
これらは、これらの要因に基づいて必要なディスク容量の例です。
- 真新しいインストールコレクターは約500MiBを使用します。
- コレクターログは最大で800MiBを使用します。
- 一時ファイル（つまり、アップグレードファイル）は1500MiB未満を使用します。
- レポートキャッシュデータは、デフォルトで500MiB未満を使用します（この図は、ラージコレクターの30分のキャッシュデータを表します）
- NetFlowを使用している場合、ディスク使用量は30GiB未満です。
合計すると、これは、コレクターディスクの使用量がNetFlowなしでは3.5GiB未満、NetFlowを有効にすると最大33.5GiBになることを意味します。