Collector Capacity

The total number of devices, instances, log events, or traps that a Collector can monitor depends on factors such as the Collector size, underlying hardware resources, collection methods, LogicModule polling intervals, and discovery schedules. To ensure reliable operation and proactively identify capacity constraints, monitor key Collector health metrics such as CPU and memory utilization, JVM statistics, and collection-method-specific performance metrics. For more information, see Monitoring your Collectors.

All Collector capacity data is derived from extensive testing conducted in the LogicMonitor Performance Scalability and Reliability (PSR) lab using dedicated Collectors for each collection method.

Collector Size Considerations

You must consider the following points related to Collector size:

• Collector capacity may vary depending on the monitoring workload and collection profile in a customer environment. To ensure consistency and reproducibility, all capacity numbers are derived using a standard test methodology based on the following assumptions:
  • Approximately 50 instances per monitored device. To estimate the number of supported instances for a given Collector, use the following formula:
    Supported device count × 50 = Estimated supported instances
    For example:
    A Collector that supports 1500 devices is estimated to support approximately 75000 instances.
    1500 × 50 = 75000 instances
  • An average Syslog event size of approximately 100-200 bytes.
  • An average of 10 traps per second per device for SNMP v2c and v3 Trap LogSources.
• LogicMonitor derives all capacity numbers using Collectors deployed on cloud virtual machines configured with instance types that provide sustained CPU performance. LogicMonitor excludes burstable, shared-core, or CPU-credit-based instance types from performance testing because their variable CPU characteristics can affect sustained Collector performance and lead to inconsistent capacity results.

Collector Size Hardware Specifications

The following table lists the Collector hardware configuration used in the LogicMonitor PSR lab to derive capacity numbers:

Capacity Matrix

The following Linux and Windows capacity matrix tables list Collector capacity by size using the following metrics:

• Requests per second (RPS) for generic collection types
• Events per second (EPS) for Syslog collection

Linux Capacity Matrix

The following matrix table lists Linux Collector capacity by size:

Windows Capacity Matrix

The following matrix table lists Windows Collector capacity by size:

Collector Capacity Tuning Recommendations

The following recommendations enable you to tune your Collector capacity:

• Use the capacity matrix as a baseline for Collector sizing. Size the Collector based on your dominant collection mix, leave headroom, and monitor Collector load, unavailable task rate, CPU, memory, JVM, and collection-specific performance. If utilization or queueing increases as you approach the Collector capacity numbers, increase the Collector size or split the workload across Collectors.
• For production environments, deploy Medium or larger Collectors to provide sufficient capacity for monitoring enterprise-scale workloads, applications, and infrastructure.
• Use Nano and Small Collectors (Linux only) only for proof-of-concept (POC), development, and internal testing environments.
• When deploying a Collector on a cloud virtual machine, choose an instance type that provides sustained CPU performance. Avoid burstable, shared-core, or CPU-credit-based instances because available CPU capacity can fluctuate over time and affect Collector performance under sustained monitoring workloads. The following table lists the recommended instance families for sustained production workloads:

• After deployment, verify Collector capacity by monitoring Collector load, task availability, CPU and memory utilization, and host resource consumption. If you observe sustained resource contention or monitoring delays, increase the Collector size or redistribute the monitoring workload across additional Collectors.
• In large environments, if a Collector reports alerts for the Unavailable Task Rate DataSource, increase the Collector capacity by allocating additional hardware resources or distributing the monitoring workload across multiple Collectors.

NetFlow Capacity

NetFlow Collector capacity is measured as the maximum sustained NetFlow/IPFIX flow processing rate (flows/second) while all certification SLOs remain within acceptable limits. The NetFlow Collector capacity data is derived from extensive testing using representative enterprise traffic profiles.

NetFlow Collector Sizing Hardware Specifications

The following Collector hardware configurations is used in LogicMonitor PSR lab:

NetFlow Traffic Profiles

Capacity Matrix

Linux Collector

Windows Collector

Compute-Based Scalability Example

This example demonstrates the scalability of an XXL Linux Collector as the host’s compute resources increase. The results show that allocating additional CPU cores increases the Collector’s NetFlow processing capacity. This positive correlation between available compute resources and flow processing throughput demonstrates that the Collector efficiently utilizes additional CPU capacity.

Adjusting Collector Size

You can adjust the collector size from the LogicMonitor portal, especially for performance tuning and increasing the collector capacity after installing it.

1. Navigate to Settings > Collectors.
2. Under the Collectors tab, select the collector whose size you want to adjust.  
3. Select the More option and then select Collector Configuration.
   
   On the Collector Configuration page, the Agent Config settings are displayed.
4. Select the collector size from the dropdown menu.
   
5. Select Save and Restart. LogicMonitor automatically verifies if your host has enough memory to support the new collector size.

If you are manually changing the collector’s config parameters, LogicMonitor runs a validity check after you select Save and Restart to ensure that no errors were made in the new configuration. If errors are detected, the missing/duplicated lines are displayed so that they can be corrected.

Small Collector

Medium Collector

Large Collector

XL Collector

XXL Collector

Minimum Recommended Disk Space

Although the Collector operates in memory, operations such as caching require available disk space on its host. The exact amount of required storage varies and depends on factors such as Collector size, configuration, NetFlow usage, number of Collector logs, and so on.

These are examples of required disk space based on these factors:

• A brand new install Collector will use about 500MiB.
• At most, Collector logs will use 800MiB.
• Temporary files (ie. upgrade files) will use less than 1500MiB.
• Report cache data will use less than 500MiB by default (this figure represents 30 minutes of cached data for a Large Collector)
• If using NetFlow the disk usage is less than 30GiB.

In total, this means Collector disk usage will be less than 3.5GiB without NetFlow and up to 33.5GiB with NetFlow enabled.