Hardware Requirements
Hardware requirements for your Opsview Monitor environment
Overview
In this section, we describe the minimum and recommended hardware specifications for Opsview Monitor servers.
Recommendations
The recommended hardware configuration is typically capable of monitoring approximately 300 hosts, but this may vary significantly depending on your monitoring configuration.
Orchestrator Server
- Four or more 64-bit CPUs (preferably multi-core)
- 8GB RAM
- 100GB available storage (with hardware RAID controller)
Collectors
- 64-bit multi-core CPU
- 2GB RAM
- 40GB available storage
See Distributed Monitoring for more details on setting up Collectors.
Remote database
- 4 or more CPU cores (64-bit)
- 16GB RAM
- 500GB available storage (with hardware RAID controller)
Minimum Requirements
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.
100 Hosts
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | All | 4 | 8 GB | c5.xlarge |
TOTAL: 4 CPU / 8 GB Memory
650 hosts
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | All (Monitoring hosts) | 2 | 8 GB | t2.large |
| 2 | Collector 1 (Cluster 1) | 2 | 2 GB | t3.small |
TOTAL: 4 CPU / 10 GB Memory
1500 hosts
| Host | Components | CPU | Memory | Example AWS Flavor |
|---|---|---|---|---|
| 1 | All (Not monitoring hosts) | 2 | 8 GB | t2.large |
| 2 | Collector 1 (Cluster 1) | 2 | 2 GB | t3.small |
| 3 | Collector 2 (Cluster 1) | 2 | 2 GB | t3.small |
| 4 | Collector 3 (Cluster 1) | 2 | 2 GB | t3.small |
| 5 | Collector 4 (Cluster 2) | 2 | 2 GB | t3.small |
| 6 | Collector 5 (Cluster 2) | 2 | 2 GB | t3.small |
| 7 | Collector 6 (Cluster 2) | 2 | 2 GB | t3.small |
TOTAL: 14 CPU / 20 GB Memory
6500 hosts
| 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
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 | 2GB |
| Opsview web | 1GB |
| Monitoring processes | 1GB |
| Opsview Reports Module | 1.5GB |
Achieving maximum scalability
Please refer to Distributed Monitoring and Distributing Functionality.
Virtualized Environments
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.
Updated about 1 year ago