Resource Requirements
This page documents recommended CPU and memory requirements for running the Monitor server and the optional Elasticsearch instance it commonly integrates with. Replace the example values below with your environment-specific numbers (for example, the values you provided).
Overview
- Server: the main Monitor backend service (API, migrations, job workers, etc.).
- Elasticsearch: optional search/indexing backend (used for dashboards, queries, and analytics).
Monitor Server (recommended example)
-
Use these as starting points. Adjust up for higher event throughput or large retention windows.
-
Small / evaluation: CPU: 1 vCPU, Memory: 0.75 GiB
-
Production (small): CPU: 2 vCPU, Memory: 4 GiB
-
Production (medium): CPU: 4 vCPU, Memory: 8 GiB
-
Production (large): CPU: 8+ vCPU, Memory: 16+ GiB
Notes:
- If you run additional background workers or enable heavy features (e.g., long-running migrations, large in-memory aggregations), provision additional CPU and memory accordingly.
- Monitor system metrics (CPU, memory, GC pause times, DB I/O) and scale horizontally or vertically as needed.
Elasticsearch (recommended summary)
Elasticsearch is typically the largest resource consumer in a Monitor deployment. The file docs/docs/05-elastic/guidelines/sizing.md contains the detailed guidance; the bullets below are a short summary aligned with that document.
- Minimum (dev / single-node testing): CPU: 1-2 vCPU, Memory: 4 GiB (heap ~2g)
- Production (small / low-volume or single-node): CPU: 4 vCPU, Memory: 16–32 GiB (heap ~8–16g)
- Production (medium / small cluster): CPU: 8 vCPU, Memory: 64 GiB (heap ~31g)
- Production (large / scaled cluster): CPU: 16+ vCPU, Memory: 128+ GiB (heap ~31g per data node)
Key points from the sizing guide:
- Node RAM: sizing.md recommends starting data-node RAM in the 16–64 GiB range for many small/medium clusters — adjust by workload.
- JVM heap: set heap = min(physicalRAM/2, ~31GB) to keep compressed pointers and leave room for OS/file cache.
- Shard sizing, disk IOPS, and network bandwidth are important factors — follow the full sizing guide for calculations and ILM recommendations.
For detailed Elasticsearch sizing guidance (nodes, heap, shards, storage), see: Elasticsearch Sizing Guidelines.
How to apply your numbers
- Pick a baseline from the examples above.
- Update your
docker-compose.ymlor Kubernetes manifests withresources.requestsandresources.limitsusing the chosen values. - For Elasticsearch, set JVM heap via environment vars or
jvm.options(keep ~50% of RAM for heap). - Monitor and adjust.