Hardware requirements
In this section, we describe the minimum and recommended hardware specifications for Opsview Monitor servers.
Recommendations Copied
The recommended hardware configuration is typically capable of monitoring approximately 300 hosts, but this may vary significantly depending on your monitoring configuration.
Orchestrator server Copied
- Four or more 64-bit CPUs (preferably multi-core)
- 8GB RAM
- 100GB available storage (with hardware RAID controller)
Collectors Copied
- 64-bit multi-core CPU
- 2GB RAM
- 40GB available storage, see Distributed Monitoring for more details on setting up Collectors.
Remote database Copied
- 4 or more CPU cores (64-bit)
- 16GB RAM
- 500GB available storage (with hardware RAID controller)
Minimum requirements Copied
The following guideline defines a few setups for different sizes, using AWS as a reference example for the machine flavors. Each host is assumed to have 20 service checks associated with intervals of 5 minutes. Keep in mind that these values are a minimum starting point and that we recommend choosing higher specs.
For 100 hosts Copied
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | All | 4 | 8 GB | c5.xlarge |
TOTAL: 4 CPU / 8 GB Memory
For 650 hosts Copied
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | All (Monitoring hosts) | 2 | 8 GB | t2.large |
| 2 | Collector 1 (Cluster 1) | 2 | 4 GB | t3.medium |
TOTAL: 4 CPU / 10 GB Memory
For 1500 hosts Copied
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | All (Not monitoring hosts) | 2 | 8 GB | t2.large |
| 2 | Collector 1 (Cluster 1) | 2 | 4 GB | t3.medium |
| 3 | Collector 2 (Cluster 1) | 2 | 4 GB | t3.medium |
| 4 | Collector 3 (Cluster 1) | 2 | 4 GB | t3.medium |
| 5 | Collector 4 (Cluster 2) | 2 | 4 GB | t3.medium |
| 6 | Collector 5 (Cluster 2) | 2 | 4 GB | t3.medium |
| 7 | Collector 6 (Cluster 2) | 2 | 4 GB | t3.medium |
TOTAL: 14 CPU / 20 GB Memory
For 6500 hosts Copied
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | Database | 4 | 16 GB | m5.xlarge |
| 2 | Datastore and Messagequeue | 4 | 8 GB | c5.xlarge |
| 3 | Timeseries | 2 | 4 GB | t2.medium |
| 4 | Collector 1 (Cluster 1) | 4 | 8 GB | c5.xlarge |
| 5 | Collector 2 (Cluster 1) | 4 | 8 GB | c5.xlarge |
| 6 | Collector 3 (Cluster 1) | 4 | 8 GB | c5.xlarge |
| 7 | Collector 4 (Cluster 2) | 4 | 8 GB | c5.xlarge |
| 8 | Collector 5 (Cluster 2) | 4 | 8 GB | c5.xlarge |
| 9 | Collector 6 (Cluster 2) | 4 | 8 GB | c5.xlarge |
| 10 | Master Server + remaining Components | 4 | 16 GB | m5.xlarge |
TOTAL: 34 CPU / 84 GB Memory
Opsview Monitor memory allocation Copied
In the table below, we describe the memory allocation for each section of the Opsview Monitor system. The memory allocations listed below are provided as guidance for most single-server deployments that monitoring approximately 300 devices.
Note
Actual requirements depends on the types and numbers of checks being performed on each device.
| System | Memory |
|---|---|
| OS | 512MB |
| MySQL | 512MB |
| Opsview daemons | 512MB |
| Opsview web | 1GB |
| Monitoring processes | 1GB |
| Opsview Reports Module | 1.5GB |
Achieving maximum scalability Copied
Please refer to Distributed Monitoring and Distributing Functionality.
Virtualized environments Copied
Opsview Monitor can run in a virtualized environment. In such an environment, disk I/O is the typical bottleneck, and so:
- Automatic snapshotting of guest Virtual Machines (VMs) causes significant I/O overhead and we would recommend that this feature is disabled or carefully managed outside of core production hours.
- An external storage array should be considered for large scale systems; for example, where thousands of hosts are monitored.
- The latest versions of hypervisor software should be installed, as well as the latest recommended drivers for storage and network operations.