You are here


Sizing Your Opsview System

One of the most common questions we have with new customers here at Opsview is “sizing”. We'd all love if it was as easy as linking you to our Knowledge Center and looking at the basic requirements, Unfortunately, reality is a bit more complex than that. I'll outline some sizing recommendations based on my personal experience as a Senior Customer Success Engineer here at Opsview, which will hopefully help put you on the right track with your new monitoring environment.

No unnecessary reading!

I've put together a chart for sizing your system on bare metal and virtualized below. For details on the selections and to give you more ideas on how to size your environment, just scroll down to the appropriate section.

Master Server – Production – Bare Metal

Hosts CPU RAM Disk Database
25 Core i3 4GB 20GB (No ODW) Local
<=100 Core i5 6GB 80GB Local
<=300 Xeon or Opteron w/ 8 cores 8GB 200GB Local
<=1000 Xeon or Opteron w/ 8+ cores 12GB 200GB Remote
>1000 Dual Xeon or Opteron w/ 16+cores 24GB 300GB Remote

Database – Production – Bare Metal

Hosts CPU RAM Disk
<=1000 Xeon or Opteron w/ 8 cores 24GB 300GB+
>1000 Xeon or Opteron w/ 8 cores 48GB 500GB+ 

Master Server – Production – Virtual

Hosts CPU RAM Disk Database
25 2 vCPU 4GB 20GB (No ODW) Local
<=100 4 vCPU 6GB 80GB Local
<=300 6 vCPU 8GB 200GB Remote
<=1000 12 vCPU 18GB 200GB Remote
>1000 16 vCPU+ 24GB 300GB Remote 

Database – Production – Virtual

Hosts CPU RAM Disk
<=300 6 vCPU 12GB 200GB+
<=1000 8 vCPU 24GB 300GB+
>1000 12 vCPU+ 48GB 500GB+ 
*These are general recommendations. Recommendations are made on the higher side of the number of hosts shown, requirements may need to be scaled in either direction depending on your specific case. If in doubt, contact the Customer Success Team.

Let's start with the basics – Opsview Atom

Opsview Atom is perhaps the easiest to size up to your hardware. It can easily be run on bare-metal or in your organizations virtual environment. But let's run over the requirements from our Knowledge Center page:
•    A CPU model that’s less than five years old
•    4GB (64-bit systems)
•    20GB available storage (with data warehouse disabled)

The first thing to decide is how you plan on using Opsview Atom. Some may use it as their primary method of monitoring. Others may choose to use it for testing of plugins or notifications for later use on a larger Opsview system. The key to sizing correctly in either case first starts with how you choose to deploy:


Primary Monitoring Environment
If you plan on using Opsview Atom as your primary monitoring environment or as a way to trial Opsview for use on a larger scale and you have some spare physical systems lying around, I'd recommend the following:

- A Core-i3 (as early as the first generation) with a minimum clock speed of 2Ghz

  • A Core-i3 will offer you enough power to monitor the 25 included devices, plus give you a little room to play around with some of the more taxing service checks and even do some minimal reporting using ODW

- 8GB of DDR3 RAM

  • 8GB of DDR3 will be more than enough to keep your system running smoothly, give you room to grow, and will make database tuning and other performance tuning easier. It also helps future proof your system should you need to monitor more than 25 devices in the future. If you only have some spare systems lying around with DDR2 or older RAM, then it's likely not quite powerful enough (and almost certainly not of the Core series CPUs). You can certainly keep this kind of system around for testing which I'll get to below.

- 80GB of available storage on 1x 7200rpm hard drive

  • This should be a fairly easy requirement to make. Regardless of your organization, you're likely to have a few spare drives bouncing around. Make sure they're at least 80GB, SATA interface (IDE simply won't due, plus if your motherboard doesn't support at least SATA2 then it's time for an upgrade!), and it's a 7200rpm drive (or faster for those with some old SAS or SCSI drives lying around). Since your database will be located on the same hardware, it is important to use the fastest drives available. If you really want to have blazing performance, consider picking up an affordable SSD.

- 1x gigabit networking port

While these specifications may be a bit overkill (especially in the RAM department), if you're using Opsview Atom in a production environment with a large number of contacts or constant access to the WebUI, you'll gain an appreciation for the level of performance this hardware can provide.

But what about those who already have Opsview Enterprise and want to do plugin development or want to use Opsview for fun projects? This is where you can get really creative.

Projects, Development and More:
- Core2Duo or newer CPU

  • Wow! When was the last time you heard about a Core2Duo? You probably used a laptop seven or eight years ago with one of these CPU's. If you have a laptop equipped with one of these, install your favorite distro on it and download the latest release of Opsview so you'll be ready to start monitoring!

- 2GB of RAM

  • Judging by the ability to use a Core2Duo, you should be safe running on DDR2 RAM (dare I say DDR?). While almost painfully slow by today's standards, this should be perfectly acceptable for testing purposes or plugin development. If you find you need to test the WebUI or ODW, consider cleaning out your desk draws. You never know, you might just find another 2GB DDR2 stick waiting to be used to its full potential!

- 10GB of storage

  • I'd highly, and I do mean “HIGHLY”, recommend using a larger disk drive. I don't even know the last time you could purchase a 10GB drive. Digging around and finding an old 120GB SATA HDD would be ideal, but you can use virtually anything you find. But whatever you do, stay away from IDE. IDE drives can be painfully slow these days, which I feel is mostly due to the fact that they're old. My personal recommendation would be an SSD, maybe an old 40GB one from an older system?

- 1x gigabit networking port

  • This probably goes without saying, but a 10/100 nic will certainly hold you back. Most laptops even from 10 years ago will have a gigabit port and even if you're using a desktop, a gigabit nic can be had for little to no money off the web. If you don't have one lying around, go and grab yourself one before you get started.

These minimum specs will build you a basic system and can likely monitor the full 25 devices included with Atom, and certainly give you enough power to use Opsview for basic testing. I personally don't use bare metal for Opsview installations generally, but it is a great way to get some use out of older hardware and is very helpful when doing performance benchmarking.


Virtualized environments are far simpler to spec out. Just make sure your environment has available resources so you don’t cause contention. Additionally, you can run Opsview Atom from within VirtualBox or VMWare Player on your desktop, leaving you with additional options for smaller environments.

Primary Monitoring Environment
- 2 vCPU

  • 2 vCPU’s should be enough to run the webUI and a modest amount of checks

- 20GB Storage

  • Again, this is without any intention of using reporting. While not included in Atom, it is good to keep this in mind should you decide to purchase Opsview and then enable reporting.

Projects, Development and More:
- 2 vCPU

  • 2GB is the bare minimum to run smoothly. If you are running this on a laptop or desktop with a limited amount of RAM, you can get away with 1GB, but do expect some potential slowness. Be sure to provision your system with at least 2GB of swap space in either case.

- 10GB Storage

  • Ideally fast storage. SSDs are ideal for virtualized environments as they offer a superior amount of IOPS compared to mechanical disks.

Opsview Pro 50-300

For customers who have purchased Opsview Pro, welcome! I hope you'll find Opsview useful and powerful, with the flexibility to grow with your company. The below specifications are great for Pro production systems as well as development and testing environments for larger Enterprise customers. Since most customers in the Pro realm will be using virtualized environments, I'm going to skip over the details on bare metal systems. Should you choose to go bare metal, you can use any of the notes below to help you size it and determine the best configuration.

Primary Monitoring Environment & Test Environments
Master Server
- VMWare, KVM, Xen, or Hyper-V
- 4-6 vCPU

  • The backing CPU's should be fairly recent. Either current or last generation Xeon or Opteron CPU's. For smaller organizations, a Core-i7 can be a great alternative for a hypervisor running a few hosts, including Opsview. Just be careful not to heavily over provision, especially if you're above 200 hosts.

- 6-8GB RAM

  • 6-8GB of RAM should be adequate for smaller systems, including running the database on the master. If your organization only has one system that acts as a hypervisor with a single backing storage array, then there is minimal benefit to having a remote database. Should you experience performance problems, consider adding an additional hypervisor or migrating the database to a stand-alone bare metal server with between 8-12GB of RAM.

- 80-200GB Storage

  • This storage needs to be on the quick side. I recommend SSDs for both the master and database servers if possible. Otherwise, a high performance raid configuration is ideal. For details, take a look at the Opsview IOPS blog post. Additionally, you may need more space depending on the retention of ODW and your expected use of the reporting module. Using Opsview to monitor your disk usage is a great way to keep on top of your system and expand the storage as needed.

Database Server (>=200 Hosts)
- VMWare, KVM, Xen, or Hyper-V
- 4-8 vCPU

  • If you do not plan on using reporting or use it lightly, then four vCPUs should be adequate. If you plan on reporting often and have a lot of concurrent web users, then aim for 8 vCPUs if possible.

- 8-24GB RAM

  • This is also dependent on reporting and your use of ODW. If you are unsure, 8GB should be adequate to get going with any installation. Routinely check your RAM usage with “free -m” and database performance recommendations using

- 300GB Fast Storage (Write Heavy)

  • Opsview is write heavy with about 2/3rd of all database activity being writes. Keep this in mind when provisioning the storage. More may be needed depending on ODW retention settings and storage should be dedicated where possible.

Opsview Enterprise <=1000 Hosts

For enterprise customers, I'll also be assuming that the system is virtualized. The database system should only be run using dedicated storage. Specifications for testing environments of this size are not provided.

Primary Monitoring Environment
Opsview Master
- VMWare, KVM, Xen, or Hyper-V
- 12 vCPU
- 18GB RAM
- 200GB Fast Storage

  • This should be raided or otherwise fast storage with minimal contention from other systems. This storage should never be shared with your database server.

Database Server
- VMWare, KVM, Xen, or Hyper-V
- 8 vCPU

  • This is less than the Master server as the database typically runs single threaded transactions and also takes care of bulk queries handled to it, making the use of additional CPUs minimal.

- 24GB RAM

  • 24GB of RAM allows you to set a very high innodb_buffer_pool_size value, allowing you to store a large amount of the database data in RAM. This can offer a substantial performance boost. Additionally, you can increase other cache values with MySQL when you have a larger amount of RAM. This will help keep things running smoothly and offer the ability to do additional tuning.

- 300GB Fast Dedicated Storage

  • Storage for the database server needs to be dedicated to insure performance. 300GB should be adequate for most installations, but monitor your database disk usage closely using Opsview to insure you have enough available.

Opsview Enterprise >1000 Hosts

For customers looking to monitor more than 1000 hosts, I recommend contacting Customer Success and reviewing your specific needs. At the very least, you will need a Master, Slave, and dedicated Database server. Using the specifications above as a guideline, you can estimate the size environment you may need. There are also additional considerations depending on the weight of checks, number of users your organization has, reporting use, and number of slaves.


One piece that I didn't touch on above is slave systems. This is mainly because the specifications of these systems can vary depending on the checks you're running and number of hosts you want to monitor with them. Additionally, slaves can be clustered together which can help distribute checks and offer some redundancy. The key things to note about any slave environment are the following:

- Slave clusters shouldn't be huge. Ideally groups of two or three 

  • What I mean by this is that slave clusters are mainly designed for redundancy. If one slave in a slave cluster goes down, then the other slaves in the cluster will pick up those checks. While checks are distributed across slaves, having too many slaves and then having a few fail can cause your remaining slaves in a cluster to become overloaded and stop reporting check results. Keeping this down to two or three well provisioned slaves can help reduce monitoring downtime should something go wrong. Finally, slaves in a cluster should be on different hardware if possible. This can help reduce the risks involved with hardware failure of a hypervisor.

- Slave clusters do not evenly distribute load

  • Slave clusters are designed mainly for redundancy, not load balancing. Some load balancing is achieved by having a cluster, but checks aren't weighted. It is possible for one slave to have a significantly higher load than another in the cluster. Be sure to provision each slave with enough resources to handle all of the checks within the entire cluster.

Slaves can also be used to help reduce the need for networking tunnels or VPN connections between sites. They should be used whenever monitoring locations are remote or may suffer from occasional poor connectivity. Using Slaves this way can help keep your monitoring alive and well, despite any outages on the master or network connectivity issues between Master and Slave.

Final Thoughts 

I hope you have found this blog helpful and informative in sizing your Opsview environment. These recommendations are based on my experience working with customers and running performance tests on my own. If you're ever in doubt, don't hesitate to contact Customer Success with your questions. Someone will be happy to discuss your specific needs with you so you can have many years of smooth and reliable performance with Opsview! 

Get unified insight into your IT operations with Opsview Monitor

wannunciata's picture
by William Annunciata,

More like this

Feb 05, 2016
By Opsview Team, Administrator

When choosing an Enterprise monitoring tool there are many considerations, but one that is almost always right at the top of the list is...

Dec 02, 2016
By Farhan Siddiqui, Developer

A guide on how to improve the performance of concurrent inserts with MySQL. 

How to benefit from AWS Application Monitoring
Jun 14, 2017
By Eric Bernsen, Marketing Analyst

Utilize the benefits of AWS application monitoring and learn how they add value to your business.