Hey! These docs are for version 6.3, which is no longer officially supported. Click here for the latest version, 6.7!

## 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/Primary 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

  • 10GB 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

HostComponentsCPUMemoryExample AWS Flavor
1All48 GBc5.xlarge

**TOTAL:** 4 CPU / 8 GB Memory

#### 650 hosts

HostComponentsCPUMemoryExample AWS Flavor
1All (Monitoring hosts)28 GBt2.large
2Collector 1 (Cluster 1)22 GBt3.small

**TOTAL:** 4 CPU / 10 GB Memory

#### 1500 hosts

HostComponentsCPUMemoryExample AWS Flavor
1All (Not monitoring hosts)28 GBt2.large
2Collector 1 (Cluster 1)22 GBt3.small
3Collector 2 (Cluster 1)22 GBt3.small
4Collector 3 (Cluster 1)22 GBt3.small
5Collector 4 (Cluster 2)22 GBt3.small
6Collector 5 (Cluster 2)22 GBt3.small
7Collector 6 (Cluster 2)22 GBt3.small

**TOTAL:** 14 CPU / 20 GB Memory

#### 6500 hosts

HostComponentsCPUMemoryExample AWS Flavor
1Database, Datastore and Messagequeue416 GBm5.xlarge
2Timeseries24 GBt2.medium
3Collector 1 (Cluster 1)48 GBc5.xlarge
4Collector 2 (Cluster 1)48 GBc5.xlarge
5Collector 3 (Cluster 1)48 GBc5.xlarge
6Collector 4 (Cluster 2)48 GBc5.xlarge
7Collector 5 (Cluster 2)48 GBc5.xlarge
8Collector 6 (Cluster 2)48 GBc5.xlarge
9Master Server + remaining Components416 GBm5.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.

Opsview daemons512MB
Opsview web1GB
Monitoring processes1GB
Opsview Reports Module1.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.