Data Processing Capacity and Telemetry Log Rate Management
Each A10 Control deployment has a defined telemetry data processing capacity. This capacity essentially limits how much incoming telemetry data (metrics, events, logs) the controller can process. A10 Control is not meant to be an unlimited data lake; it balances between providing useful analytics and protecting itself from being overwhelmed by telemetry data floods.
The following concepts are important for understanding and managing capacity:
Overall Data Throughput
The controller software has defined limit on how many telemetry per second it can handle, depending on the deployment size:
- Single-node deployment: Supports up to 3.5K logs per second.
- Multi-node deployment: Supports up to 8K logs per second.
Telemetry Processing Capacity Allocation
In multi-tenant scenarios (multiple organization accounts on one controller), the total log processing capacity is shared among all orgs. By default, it’s a common pool – all organizations can collectively use the full capacity if needed. However, a super-admin (controller admin) can reserve or allocate portions of capacity to specific organizations.
For example, if you have two tenant organizations and one is very log-heavy, you might dedicate 60% capacity to Org A and leave 40% shared (or reserved) so that Org B or future orgs are not starved. Any new organization by default starts in the shared pool unless specifically assigned a dedicated slice. This allocation ensures fairness or guaranteed service levels for important tenants.
Telemetry Log Rate on Devices
On the Thunder devices, there is a configuration for log rate limiting. The “log rate” on a device (or per partition on the device) controls how many logs per second that device will send to A10 Control at maximum. By default, A10 Control can manage these log rate settings automatically: it communicates to each device an appropriate log rate based on current capacity and number of devices. This automatic adjustment prevents devices from overrunning the controller with logs. If an administrator manually sets log rates on devices, they must ensure that the sum of all those rates for each organization does not exceed the allocated log processing capacity for that organization on the controller. Essentially, if you have increased a controller’s capacity or if you notice dropped logs, you might need to tune device log rates accordingly.
Storage Capacity Alerts
Related to processing capacity is the physical storage usage. A10 Control monitors its own disk/persistent volume usage. Threshold-based alerts (at 75%, 85%, 90%, 95% full) will trigger to warn administrators as the storage fills up. If usage hits very high levels (e.g. 95%), certain functions might start failing (for instance, new logs might not be stored). Administrators should heed those alerts by either cleaning up data (if possible), increasing the storage allocation, or rotating out old data. Configuring the email server in the System settings is recommended so that these storage alerts send out emails to admins, ensuring you don’t miss a critical storage issue.