Opsview Monitor has many daemons running on both the Maser and Slave Node servers to allow for efficient monitoring of hosts. Some of these...
You are here
Opsview - An Architectural Review
Opsview is a IT and business service monitoring solution that users install on servers, virtual machines or in the cloud such as on Amazon AWS, to allow monitoring of every aspect of an IT estate from VMware and Oracle, to Microsoft Windows and Cisco networks. This article is intended to give users or prospective users an overview into the design of an Opsview system, and what the terminology means and why we configure it differently in certain situations.
1. Architectural overview of Opsview
In its most basic of forms Opsview consists of a Master server, and a database. The master server does the monitoring (polling, receiving traps, NetFlow, querying via WMI, etc) and returns the data which is stored in the MySQL database. The dashboards, reports, etc then analyse that data and display it for users (alerting aside, etc).
A standalone master can generally monitor around 300 servers (depending on hardware, load, service checks per host, etc) - however sometimes the master server can become “overloaded” (too many hosts being monitored by the one monitoring server), so users can choose to use slave servers to offload this workload onto a secondary piece of hardware - i.e. 250 on the master, 250 on the slave - with the slave monitoring 250 Windows servers, and the Master monitoring 250 Linux servers, for a simple example.
This collection of the “Windows Servers” data is done by the slave server itself (configured via the master server which pushes the changes/instructions out). The slave collects the data, i.e. C:/ usage, CPU usage, service status, etc and passes the results back to the master - so that the master can store the results in the database (ODW), and use them for dashboards, reports, etc. A simple example of a Master server and a slave cluster (same concept but 2 slave nodes in high-availability) and the ‘splitting of hosts’ between monitoring instances can be seen here:
This “passing” of data from the slave servers to the master server is done via an SSH tunnel setup using key exchange, so you can be sure that the results are secure, especially if they are going over a WAN link / the internet. The connection of the slaves to the master server is done via the SSH port (TCP 22) which would need to be opened on the firewall, however with a bit of tweaking we can modify it to use almost any port desired. The slaves can also connect either via a forward SSH tunnel; reverse SSH tunnel, or “Passive”, as outlined below:
2. Potential Architectures
Now that we’ve covered off the terms / technology, we can dive into architecture. Generally, architecture can be split into 1 of 2 scenarios – cloud hybrid or on-premise.
Scenario 1 - Using a cloud provider
We could architect Opsview in the cloud (PaaS/IaaS) using a provider such as Amazon Web Services. In this scenario, we would install the Opsview master in the cloud, (i.e. in a VPC in Amazon AWS) and access it via the internet / WAN. We would then install a slave server on each location, 1 on Customer A and 1 on Customer B, for example, and then have “A Slave” monitor the entire Customer A infrastructure, and “B Slave” monitor all of the Customer B infrastructure. These 2 slaves would then pass back their results via the SSH tunnel to the Opsview master in the cloud, for use in dashboards, reports, alerts, etc. This requires a server on each location, with connectivity to the Opsview Master in the cloud.
Scenario 2 - Using an On-Premise solution
We could also use a scenario similar to above, but avoid the cloud and use entirely on-premise hardware. In this scenario, we would have the Opsview Master at our HQ / Data Centre, and a slave server at Customer A and customer B, and again an SSH tunnel between HQ and the 2 slave servers. This may even require no ports opening depending on the network configuration (VTP across 2 locations, etc).
Again, we would split the server monitoring, so “Opsview Master” monitors the HQ/Data centre servers, and “Customer A/B” slaves monitor the customer A/B hardware respectively- and users would be able to login to the Master on the HQ location via a GUI, and see the data of both sites in the single pane of glass.
Scenario 3 – Using an On-Premise solution without slaves
If we have a large network, or we aren’t allow to install a slave on premise, then the 3rd scenario we have is to simply open up ports to allow port 5666/5667 into the customers network, and add the hosts directly to our Opsview system using the GUI on the master and connect via the slave. This requires direct connectivity between the Opsview Master and the monitored device via port 5666 (NRPE).
3. Closing Thoughts
There are numerous methods of installing and architecting Opsview – one of which is sure to fit your environment. Providing the basics are understood – such as the Master/Slave concept, how the two connect, etc then you should be up and running and monitoring your entire estate or your entire customer base in next to no time.
More like this
Outlining the best ways to restrict SSH commands and make SSH more secure.
Uprooting the Opsview Master server is probably last on every administrator’s to-do list. But it’s not a perfect world and extenuating...