コレクター容量

最終更新日：2026年8月14日

コレクターが処理できるデータの量は、コレクターの構成とリソースによって異なります。コレクターのデータ収集の負荷とパフォーマンスを監視して、中断を最小限に抑え、コレクターがダウンしたときに通知することができます。見るコレクターの監視.

大規模な環境で、コレクターの使用不可タスクレートデータソースでアラートが発生している場合は、コレクターを調整して監視容量を増やす必要がある場合があります。

デバイス容量の制限

次の表は、さまざまなサイズのコレクターの容量を示しています。これは、XNUMX 秒あたりの要求数 (RPS) で測定されます (XNUMX 秒あたりのイベント数 (EPS) で測定される Syslog を除く)。

注意：

すべてのデバイスに 50 個のインスタンスをアタッチしました。したがって、インスタンスの数を取得するには、デバイスの数に 50 を掛けます。たとえば、50 x 211 (デバイス) = 10550 インスタンスです。
これらの測定値は推定値であり、実際の容量は運用環境によって異なる場合があります。

プロトコル	小さなコレクター	ミディアムコレクター	大型コレクター	特大（XL）コレクター	ダブルエクストララージ（XXL）コレクター
	CPU: 1 インテル Xeon ファミリーシステムメモリ：2GiB JVMの最大メモリ：1GiB	CPU: 2 インテル Xeon E5-2680v2 2.8GHz システムメモリ：4GiB JVMの最大メモリ：2GiB	CPU: 4 インテル Xeon E5-2680v2 2.8GHz システムメモリ：8GiB JVMの最大メモリ：4GiB	CPU：8 システムメモリ：16GiB JVMの最大メモリ：8GiB	CPU：16 システムメモリ：32GiB JVMの最大メモリ：16GiB
SNMP v2c （Linux）	300 台の標準デバイス 76RPS	1000 台の標準デバイス 256RPS	4000 台の標準デバイス 1024RPS	8000 台の標準デバイス 2048RPS	15000 台の標準デバイス 3840RPS
SNMP v3	855 台の標準デバイス 220RPS	1087 台の標準デバイス 278RPS	1520 台の標準デバイス 390RPS	2660 台の標準デバイス 682RPS	4180 台の標準デバイス 1074RPS
HTTP	320 台の標準デバイス 160RPS	1400 台の標準デバイス 735RPS	2400 台の標準デバイス 1260RPS	4500 台の標準デバイス 2000RPS	7500 台の標準デバイス 3740RPS
WMI	211 台の標準デバイス 77RPS	287 台の標準デバイス 102RPS	760 台の標準デバイス 272RPS	1140 台の標準デバイス 409RPS	1330 台の標準デバイス 433RPS
バッチスクリプト	94 台の標準デバイス 5RPS	124 台の標準デバイス 7RPS	180 台の標準デバイス 11RPS	295 台の標準デバイス 17RPS	540 台の標準デバイス 32RPS
演奏者	200 台の標準デバイス 87RPS	400 台の標準デバイス 173RPS	800 台の標準デバイス 347RPS	TBA	TBA
JMX	1000 台の標準デバイス 416RPS	2500 台の標準デバイス 1041RPS	5000 台の標準デバイス 2083RPS	TBA	TBA
Syslog	TBD	500 EPS （イベントサイズを100〜200バイトと想定）	2500 EPS （イベントサイズを100〜200バイトと想定）	4000 EPS （イベントサイズを100〜200バイトと想定）	7000 EPS （イベントサイズを100〜200バイトと想定）
SNMP v2 トラップ	TBD	17 台の標準デバイス	87 台の標準デバイス	140 台の標準デバイス	245 台の標準デバイス
SNMP v3 トラップ	TBD	14 台の標準デバイス	70 台の標準デバイス	112 台の標準デバイス	196 台の標準デバイス

容量は、監視対象デバイスごとに検出する必要があるインスタンスの数にも依存します。たとえば、各デバイスが 10,000 インスタンスのロードバランサーである場合、コレクターの容量は少なくなります。各デバイスが数百のインターフェイスを持つスイッチである場合、検出によって制限されるため、コレクターの容量が少なくなる可能性があります。

注意：

本番の重要なアプリケーションとインフラストラクチャを監視するには、要件に応じて中規模以上のサイズのコレクターを使用することをお勧めします。テスト目的で小さいサイズのコレクタを使用できます。
コレクタが Amazon EC2 インスタンスで実行されている場合は、クレジットベースのインスタンスタイプ (T5 など) ではなく、固定パフォーマンスインスタンスタイプ (M5 や C2 など) を使用することをお勧めします。
この表にはナノコレクターのサイズは含まれていません。ナノコレクターはテスト用に使用されるため、推奨されるデバイス数の容量は割り当てられていません。
JDK 11 (コレクターバージョン 28.400 以降でサポート) を使用するコレクターは、同じハードウェア上の以前の JDK 10 コレクターよりもメモリと CPU の使用量が約 8% 増加します。
SNMP v2 および v3 トラップログソースの推定コレクタパフォーマンス数値の場合、各デバイスが 10 秒あたり XNUMX 個のトラップを生成すると想定しています。

VM のコレクターのメモリ要件

Collectorのシステムメモリ割り当ての一部は、スタンドアロンスクリプトエンジン（SSE）専用であり、デフォルトで有効になっており、スクリプトデータソース（Groovyスクリプト）の実行に使用されます。

コレクターサイズ	SSEメモリ要件
S	0.5GiB
技法	1GiB
L	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コレクターの容量は、すべての認証SLOが許容範囲内に収まる状態で、NetFlow/IPFIXフローを最大持続的に処理できるレート（フロー/秒）として測定されます。NetFlowコレクターの容量データは、LogicMonitorパフォーマンス・スケーラビリティ・信頼性ラボ（PSR）で、代表的な企業トラフィックプロファイルを使用して実施された広範なテストから得られています。

注意： 実際のコレクターのパフォーマンス（フロー/秒）は、プロトコル（v9、IPFIX）、NBAR/NBAR2アプリケーションの可視性（オフ、オン）、エクスポーター数、テンプレートの複雑さ、更新レート、可変長フィールド、フローの形状（安定、不均一、バースト）など、複数の要因に依存します。

推奨事項：

最適なパフォーマンスを得るには、NetFlow データの処理専用のコレクターを使用してください。NetFlow と、SNMP、BatchScript、WMI、その他のデータ収集タイプの監視など、他のタスクに同じコレクターを使用すると、コレクター全体のパフォーマンスが低下する可能性があります。
NetFlowデータの処理はCPU負荷が高いため、NetFlowコレクターホストのCPU使用率を監視してください。CPU使用率が継続的に高い場合は、CPUコア数を増やしてサポートするフロー数を増やしてください。CPU容量を増やしてもパフォーマンスが改善されない場合は、より大型のコレクターを使用してください。
コレクターのサイズを選択する際は、容量マトリックスの中で、想定されるトラフィック量に最も近いトラフィックプロファイルを使用してください。

NetFlowコレクターのサイジングハードウェア仕様

LogicMonitor PSRラボでは、以下のコレクターハードウェア構成が使用されています。

構成パラメーター	アマゾン Linux	Windows Serverの2025
AWS EC2インスタンスファミリー	C8i	C8i
プロセッサプラットフォーム	カスタムIntel Xeon 6（Granite RapidsクラスのカスタムAWS Intel Xeon 6）コンピューティング最適化済み最強のAWS Intelコンピューティングベースライン	カスタムIntel Xeon 6（Granite RapidsクラスのカスタムAWS Intel Xeon 6）コンピューティング最適化済み最強のAWS Intelコンピューティングベースライン
OSイメージ	Amazon Linux 2023 AMI 2023.12.20260727.0 x86_64 HVM カーネル 6.18	Microsoft Windows 2025 Datacenterエディション
アーキテクチャ	x86_64	x86_64
ファームウェア/ブートモード	最新のNitro AMIではUEFIが推奨/デフォルトです。	UEFI

NetFlowトラフィックプロファイル

プロファイル名	プロトコル	NBAR/NBAR2	テンプレ	複雑性／基数
スタンダードエンタープライズ（NBARなし）	NetFlow v9	オフ/該当なし	1-10	標準フィールド; IPv6無効; 中程度のカーディナリティ; 安定; バーストなし
NBARなしのIPFIX Enterprise	IPFIX/v10	オフ/該当なし	1-10	標準＋オプションテンプレート、中／高フィールド、IPv6 25%、軽度のバースト
NBAR可視化機能を備えた標準エンタープライズ	NetFlow v9	On	1-10	標準フィールド; IPv6無効; 中程度のカーディナリティ; 安定; バーストなし
IPFIX EnterpriseとNBAR可視化機能	IPFIX/v10	On	1-10	オプションテンプレート、変数/ベンダーフィールド、IPv6 25%、軽度のバースト

容量マトリックス

Linuxコレクター

プロファイル名	S	技法	L	XL	XXL
スタンダードエンタープライズ（NBARなし）	35,117	56,344	82,977	126,588	194,259
NBARなしのIPFIX Enterprise	9,142	16,627	27,132	46,296	79,586
NBAR可視化機能を備えた標準エンタープライズ	6,780	17,911	39,678	94,507	227,834
IPFIX EnterpriseとNBAR可視化機能	5,296	16,137	40,180	108,715	298,257

Windowsコレクター

プロファイル名	S	技法	L	XL	XXL
スタンダードエンタープライズ（NBARなし）	29,784	52,341	83,045	137,423	229,007
NBARなしのIPFIX Enterprise	5,779	10,778	17,954	31,331	55,102
NBAR可視化機能を備えた標準エンタープライズ	5,440	12,247	23,800	49,141	102,491
IPFIX EnterpriseとNBAR可視化機能	7,697	19,609	42,165	97,222	226,789

コンピューティングベースのスケーラビリティの例

この例は、ホストの計算リソースが増加するにつれて、XXL Linux Collectorのスケーラビリティがどのように向上するかを示しています。結果から、CPUコアを追加で割り当てると、CollectorのNetFlow処理能力が向上することがわかります。利用可能な計算リソースとフロー処理スループットの間に正の相関関係が見られることから、Collectorは追加のCPU容量を効率的に活用していることがわかります。

OS	コレクターサイズ	プロファイル名	サポートされているフロー	コレクターホストのハードウェア構成
Linux	XXL	スタンダードエンタープライズ（NBARなし）	194,259	16 vCPU、32 GB RAM
Linux	XXL	スタンダードエンタープライズ（NBARなし）	433,500	32 vCPU、64 GB RAM

注意： 利用可能なコンピューティングリソースを増やすことで、コレクターの処理スループット（1秒あたりのフロー数）を向上させることができます。ただし、ワークロードのスケーラビリティは線形ではなく、ワークロードによってパフォーマンスが変動する場合があります。

コレクタサイズの調整

特に、LogicMonitor ポータルからコレクタサイズを調整できます。性能調整設置後のコレクタ容量の増加。

MFAデバイスに移動する設定 > コレクター.
下 コレクター タブで、サイズを調整するコレクターを選択します。
まず その他 オプションを選択してから コレクター構成.

「コレクター構成」ページに、エージェント構成設定が表示されます。
ドロップダウンメニューからコレクタサイズを選択します。
選択 保存して再起動します。 LogicMonitor は、ホストに新しいコレクタサイズをサポートするのに十分なメモリがあるかどうかを自動的に検証します。

注意：

古いコレクターは、インストール後にパラメーターが変更されていない場合でも、ドロップダウンに現在のサイズを「カスタム（xGiB）」として表示します。これは、コレクターがインストールされてからサイズの定義が変更されたためです。コレクターの構成が最新であることを確認する場合は、必要なサイズ（または最初にインストールしたサイズ）を選択し、[保存して再起動]を選択します。
コレクターのサイズを変更しても、そのサイズに関係のないパラメーターには影響しません。以下のセクション「構成の詳細」にリストされているパラメーターは、コレクターのサイズの変更によって影響を受ける唯一のパラメーターです。

コレクターの構成パラメーターを手動で変更している場合、LogicMonitor は、ユーザーが選択した後に有効性チェックを実行します。 保存して再起動します 新しい構成でエラーが発生していないことを確認するため。エラーが検出された場合は、欠落/重複した行が表示され、修正できるようになります。

小さなコレクター

設定ファイル	技術パラメータ	詳細説明
ラッパー.conf	wrapper.java.initmemory = 128	コレクターの最小Javaヒープサイズ（MiB）
ラッパー.conf	ラッパー.java.maxmemory = 1024	コレクターの最大Javaヒープサイズ（MiB）
sbproxy.conf	wmi.stage.threadpool.maxsize = 100	sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ
sbproxy.conf	wmi.connection.threadpool.maxsize = 50	sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ
エージェント.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	無し

ミディアムコレクター

設定ファイル	技術パラメータ	詳細説明
ラッパー.conf	wrapper.java.initmemory = 512	コレクターの最小Javaヒープサイズ（MiB）
ラッパー.conf	ラッパー.java.maxmemory = 2048	コレクターの最大Javaヒープサイズ（MiB）
sbproxy.conf	wmi.stage.threadpool.maxsize = 200	sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ
sbproxy.conf	wmi.connection.threadpool.maxsize = 100	sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ
エージェント.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	無し

大型コレクター

設定ファイル	技術パラメータ	詳細説明
ラッパー.conf	wrapper.java.initmemory = 1024	コレクターの最小Javaヒープサイズ（MiB）
ラッパー.conf	ラッパー.java.maxmemory = 4096	コレクターの最大Javaヒープサイズ（MiB）
sbproxy.conf	wmi.stage.threadpool.maxsize = 400	sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ
sbproxy.conf	wmi.connection.threadpool.maxsize = 200	sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ
エージェント.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コレクター

設定ファイル	技術パラメータ	詳細説明
ラッパー.conf	wrapper.java.initmemory = 1024	コレクターの最小Javaヒープサイズ（MiB）
ラッパー.conf	ラッパー.java.maxmemory = 8192	コレクターの最大Javaヒープサイズ（MiB）
sbproxy.conf	wmi.stage.threadpool.maxsize = 800	sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ
sbproxy.conf	wmi.connection.threadpool.maxsize = 400	sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ
エージェント.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コレクター

設定ファイル	技術パラメータ	詳細説明
ラッパー.conf	wrapper.java.initmemory = 2048	コレクターの最小Javaヒープサイズ（MiB）
ラッパー.conf	ラッパー.java.maxmemory = 16384	コレクターの最大Javaヒープサイズ（MiB）
sbproxy.conf	wmi.stage.threadpool.maxsize = 1600	sbwinproxy.exeでWMIクエリ/フェッチデータを処理するスレッドの最大サイズ
sbproxy.conf	wmi.connection.threadpool.maxsize = 800	sbwinproxy.exe内のリモートマシンに接続するWMIのスレッドの最大サイズ
エージェント.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になることを意味します。

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

文化