Sizing & Capacity
This page gives practical, real-world starting points for sizing a GridNMS deployment: how many collectors to run, how much CPU/RAM/disk to give each collector host, how to size the server that runs the GridNMS application, and how much disk to plan for metrics and log retention.
How GridNMS is laid out
Section titled “How GridNMS is laid out”Understanding where the work happens makes sizing much easier:
- Collectors are lightweight sensors. A collector pings devices, polls them for metrics, and receives syslog and SNMP traps, then ships the raw data back over a single outbound connection. It does very little processing itself, so it stays small even when watching a lot of devices.
- The server does the heavy lifting. All the interpretation, aggregation, charting, detection, and storage happens on the GridNMS server. This is where CPU and memory scale with the size of your environment.
- Storage is dominated by metrics and logs. The relational data (devices, events, configuration) is small. What actually grows your disk is the history of metric samples and the volume of ingested logs — both driven by how much you collect and how long you keep it.
Keep this split in mind: add collectors for reach and throughput; size the server for scale; size disk for retention.
How many devices per collector
Section titled “How many devices per collector”A single collector can comfortably watch many devices across the networks you assign to it. Use these tiers as a rule of thumb:
| Collector tier | Devices watched | Typical use |
|---|---|---|
| Small | up to ~250 | A single office or small site |
| Medium | ~250–1,000 | A campus or busy site |
| Large | ~1,000–2,500 | A large site or data-centre segment |
These ranges assume standard polling intervals and a typical mix of interface, CPU, memory, and environmental metrics. Very high metric density (large chassis switches with hundreds of active ports, aggressive polling intervals, or heavy syslog volume) pushes you toward the lower end of each range.
When to add another collector
Section titled “When to add another collector”Add collectors for reach and resilience, not just raw device count:
- Per site. Run at least one collector at each physical location. A collector can only reach the networks you assign it, so remote sites need their own.
- Per isolated segment. If a single collector can’t route to every subnet (firewalled zones, DMZs, out-of-band networks), give each reachable segment its own collector.
- Per throughput. If a site pushes a large, steady volume of syslog and traps, or has more devices than a single collector tier comfortably covers, split the load across several collectors.
See What Is a Collector? for the “one per site or segment” model and Networks & Sites for how assignment defines what each collector watches.
Collector host requirements
Section titled “Collector host requirements”Because collectors are lightweight, their hosts are modest. Size the host for the number of devices it watches:
| Devices watched | vCPU | RAM | Disk |
|---|---|---|---|
| up to ~250 | 1 | 1 GB | 5 GB |
| ~250–1,000 | 2 | 2 GB | 10 GB |
| ~1,000–2,500 | 2–4 | 4 GB | 20 GB |
Collector disk is used for the software plus a small local buffer that holds data briefly if the connection to GridNMS drops. Give it extra headroom if you expect long or frequent outages, since the buffer grows until the connection recovers.
Server (self-hosted) host requirements
Section titled “Server (self-hosted) host requirements”The GridNMS server host runs the application and its storage, so it scales with your total device count (across all collectors) and your log volume. Size it for the whole deployment, not a single site:
| Total devices monitored | vCPU | RAM | Disk (base) |
|---|---|---|---|
| Small — up to ~250 | 2 | 8 GB | 50 GB |
| Medium — ~250–1,500 | 4 | 16 GB | 100 GB |
| Large — ~1,500–5,000 | 8+ | 32 GB+ | 250 GB+ |
The Disk (base) column covers the application and a modest amount of history. It does not include long metric- or log-retention windows or high log volumes — add the storage from the next section on top.
Storage for metrics and logs
Section titled “Storage for metrics and logs”Metrics and logs are what actually drive disk growth, and both are governed by a retention policy you configure — either by age (keep the last N days) or by size (cap total storage). Two things determine how much disk you need:
- How much you collect — more devices, more interfaces, and more frequent polling all produce more metric samples; chattier devices produce more logs.
- How long you keep it — longer retention means more history on disk.
Metrics
Section titled “Metrics”Metric storage grows with the number of monitored data points and how long you keep them. As a planning rule of thumb per retention window:
| Deployment | Metrics disk (rough) |
|---|---|
| Small — up to ~250 devices | ~5–15 GB per 30 days |
| Medium — ~250–1,500 devices | ~15–60 GB per 30 days |
| Large — ~1,500–5,000 devices | ~60–200 GB per 30 days |
Metrics are stored efficiently, so history is relatively cheap — but if you keep a year of high-resolution data across thousands of devices, plan disk accordingly (roughly scale the 30-day figures by the number of months you retain).
Log storage depends almost entirely on how much syslog and trap traffic your devices send, which varies enormously between environments. Estimate from your own daily log volume and your retention window:
| Daily log volume | Disk per 30 days (rough) |
|---|---|
| Light — a few GB/day | ~30–100 GB |
| Moderate — 10–20 GB/day | ~300–600 GB |
| Heavy — 50+ GB/day | ~1.5 TB+ |
Because a single noisy device (or a debug-level logging change) can multiply your log volume overnight, logs are the storage line most worth watching. To keep disk predictable you can:
- Set a shorter retention window for logs than for metrics.
- Cap retention by size so storage never exceeds a fixed budget.
- Reduce what devices log at the source where you don’t need the detail.
Putting it together
Section titled “Putting it together”A worked example for a medium deployment — 3 sites, ~800 devices total, moderate log volume, 30-day retention:
- Collectors: 3 (one per site), each a 2 vCPU / 2 GB host.
- Server: 4 vCPU / 16 GB, ~100 GB base disk.
- Metrics: budget ~30–50 GB for a 30-day window.
- Logs: budget ~300–600 GB for a 30-day window (adjust to your measured daily volume).
- Total server disk: start around 500 GB and grow with retention.
Start from the tier that matches your environment, deploy, and then let real usage guide you — GridNMS shows you your actual metric and log volumes, so you can right-size disk and retention once you have a few weeks of data.