Use this article to size a Sensor Collector deployment: how much CPU, RAM, and disk it needs, and how many collectors to deploy.
Sizing depends on three inputs:
- Number of objects — An object is a monitored entity that reports metrics on a fixed cadence — for example, a network interface via Telemetry Collector, or a TWAMP session via Sensor Agent.
- Reporting frequency — The frequency with which a device reports metrics associated to an object (30 seconds, 1 minute, 5 minutes). This can be a push or a pull.
- Rate or delta metrics — Metrics that calculate changes over time (e.g., byte rates). These metrics require additional memory to cache previous values. This is in contrast with pass-through metrics that are passed directly through the Sensor Collector to Crosswork Assurance.
CPU Requirements
A Sensor Collector requires 4 cores of CPU.
Memory Requirements
A Sensor Collector requires 4 GB of memory.
Advanced Memory Considerations When Using Rate/Delta Metrics
Rate and delta metrics require custom configuration in a Sensor Collector by a CX engineer. Memory usage scales with the number of rate/delta metrics per object. Each rate/delta metric caches its previous sample in memory, consuming additional RAM compared to pass-through metrics. If you want to customize your memory usage to consider rate/delta metrics, use the following table as guidance:
| Size | Rate/Delta Metrics per minute | Memory Usage |
|---|---|---|
| Small | < 10000 | 2 GB |
| Medium | 10000-60000 | 4 GB |
| Large | 60000-120000 | 8 GB |
Disk Sizing for Outages
The Sensor Collector buffers data on disk when it can't reach Crosswork Assurance. Once Crosswork Assurance acknowledges a batch, the Sensor Collector deletes its copy of the batch, allowing disk usage to stay low during normal operation.
The buffer volume isn't capped, so the Sensor Collector can retain data during an outage for as long as you provision adequate disk space to cover it. No data is dropped as long as there's enough room. Size the volume for the longest outage you need to survive; the 100 GB minimum is a starting point for a Sensor Collector, not a fixed retention window. Use the following table as guidance:
Data retention duration with the 100 GB minimum:
| Objects | 30-second reporting | 1-minute reporting | 5-minute reporting |
|---|---|---|---|
| 1,000 | ~48 hours (2 days) | ~96 hours (4 days) | ~480 hours (20 days) |
| 10,000 | ~5 hours | ~10 hours | ~48 hours (2 days) |
| 60,000 | ~1 hour | ~2 hours | ~10 hours |
Additional storage needed per additional hour of data retention coverage:
| Objects | 30-second reporting | 1-minute reporting | 5-minute reporting |
|---|---|---|---|
| 1,000 | 2 GB/hour | 1 GB/hour | 0.2 GB/hour |
| 10,000 | 20 GB/hour | 10 GB/hour | 2 GB/hour |
| 60,000 | 120 GB/hour | 60 GB/hour | 12 GB/hour |
The tables above assume an average number of metrics reported in an object. To estimate disk for a specific metrics payload size and outage duration:
Disk ≈ Metric Payload Size × (3600 / cadence_seconds) × objects × outage_hours
Sensor Collector Capacity Based on Reporting Frequency
A single Sensor Collector processes up to 120,000 objects/minute. Shorter reporting frequencies mean each object reports more often, so reporting frequency sets how many concurrent objects a collector can hold:
| Reporting Frequency | Max objects / Sensor Collector |
|---|---|
| 30 seconds | 60,000 |
| 1 minute | 120,000 |
| 5 minutes | 120,000 |
CPU is the primary limit — capacity scales roughly linearly with CPU.
© 2026 Cisco and/or its affiliates. All rights reserved.
For more information about trademarks, please visit: Cisco trademarks
For more information about legal terms, please visit: Cisco legal terms