There are three different ways to get started with Opsview Monitor - they all make it easy to get started quickly; which method suits you best will depend upon your environment.
Always check our system requirements here before following any of these install methods.
We provide pre-built Virtual Machines for VMware and Hyper-V or an AMI image for Amazon Web Services (AWS). The Virtual Machines and AMI Image are normally the easiest and quickest way to deploy Opsview Monitor. They run on the Ubuntu distribution of the GNU/Linux Operating System and include all of the packages and configuration for a complete setup of each of the different Opsview Monitor Editions.
You can find full instructions for downloading and installing the Opsview Monitor Virtual Machines here and instructions for deploying the Amazon Web Services AMI.
The Opsview Monitor installation script makes the process of installing from package repositories onto any of our supported Operating Systems quick and easy. This is normally the best install option if you would prefer to use another Operating System to the one used in our pre-built Virtual Machines or want to use physical hardware rather than a Virtual Machine.
You can find full instructions for using the Opsview Monitor automatic install script here.
You can also install the Opsview Monitor packages direct from the Opsview repositories in any of the supported Operating systems. This method is easy to set up but will require more configuration interaction than the scripted installation. This is normally the best method for installing if you have any special requirements like setting up High Availability, Disaster Recovery or need to access the repositories in a special way because you are in a dark environment.
You can find full instructions for accessing the Opsview Monitor repositories and installing the packages here.
When getting started with you will often come across “Hosts” and “Services”, these are the most basic components of monitoring within Opsview Monitor.
A Host is a monitored system. In a physical environment this would be a router, switch, server, etc. For a virtualized environment hosts would also include each Virtual machine with a unique IP address. For example if you had one server running ESXi which hosted 5 Virtual Machines your total host count would be 6 (1 for the ESXi server and 5 Virtual Machines).
Opsview Monitor licensing is based upon the number of monitored hosts.
Services are the things we monitor on the hosts, these could be almost anything but examples could be CPU, Memory, Disk Space or Interface throughput. Within Opsview Monitor you can monitor as many services per host as you require without any additional licensing costs.
There are a few different ways of monitoring hosts and services in Opsview Monitor; you can use the Opsview Agent, agentless checks or SNMP. Understanding the differences between these different methods is important to finding the rights checks and getting them set up.
The Opsview Monitor Agent runs directly on the monitored host and allows Opsview Monitor to run plugins (scripts) on the host and then pass the results back to the monitoring system. The advantage of the agent is that it has local access to many of the machines resources and does not rely on exposed services or APIs.
The Opsview Monitor Agent is available for Windows and Linux systems. You can find more about the available agents here.
Agentless checks run Opsview Monitor plugins on the Opsview Monitor system which then query the host. These are normally designed for services that are available remotely like applications with an API, HTTP interface, or technologies like Windows WMI.
SNMP is most common on network devices but is also available on some other systems. Opsview Monitor is able to query SNMP devices with SNMP polls and accept SNMP traps, where the device sends the SNMP data directly to Opsview Monitor.
Opsview Monitor comes with some pre-built SNMP Service Checks but can quickly and easily monitor many SNMP enabled devices by accepting a MIB file and then allowing you to run an SNMP Walk to find all of the available data. You can find instructions on doing this here.
Information on setting up SNMP traps in Opsview Monitor can be found here.
Now you are collecting lots of information about the status of your hosts and services you are going to need ways to easily and clearly present and report information about them. Luckily, Opsview Monitor makes this very straight forward using a few easy to understand tools and views.
Hashtags are a simple way of breaking up hosts and services into logical groups that mean something to you and your organization. They allow you to tag systems into any grouping you choose, for example you could have Hashtags for locations, technologies, system responsibility or departments, but they can be for any grouping that makes sense within your environment.
Hashtags are the made up of the intersection of hosts and services that you select, put another way this means you select the combination of hosts and services you require for a Hashtag.
For example, if I was setting up some Hashtags based upon location, to set up a “London” Hashtag I would select all of the hosts in my London office and then select all services for these hosts, because all of those hosts and services are in London.
If I was setting up a “Database” Hashtag as part of a group of Technology Hashtags I would select all of the hosts that include a database system and then select all of the database related services, this means even if these hosts include Operating System service checks alongside the database ones, the Hashtag will just include the database information.
If I was interested in the CPU of all my hosts I could also set up a Hashtag that just selects the CPU services checks and includes all hosts.
Hashtags require a bit of understanding on how they break up hosts and services but once you understand them they are a very quick, easy and powerful way to break up your monitoring information into easy to use data and visualizations.
Hashtags have their own view which lets you see exactly what is going on in your custom Hashtag groupings, any outage on any Hashtag host or service will show that Hashtag as down. Hashtags also appear in a few different dashlets in the Opsview Monitor dashboards.
Hashtags are very useful for alerts, more on that later.
Many of the Opsview Monitor reports are based upon the information provided by Hashtags, there is more information about that in the Reporting section of this guide.
Opsview Monitor's Business Service Monitoring (BSM) functionality allows you to create groupings of hosts and services a bit like Hashtags but they go a bit further as they allow you to define Business Service dependencies and redundancies. Within Business Services you can easily define Components, which are sets of related service checks and then set the Operational Zone. If you have a clustered pair of Exchange servers then you can add them both to a Component and then set a 50% Operational Zone, meaning that only one of the two of them are required to be up (available) at any one time for this part of the Business Service to be operational. You can then group multiple Components into a Business Service.
Business services allow you to easily see the overall status of your high level services. This gives a much broader view of your overall service status than just viewing individual host status. You can see the status of Business Services in the dedicated BSM view or using dashlets within the dashboards.
Just like Hashtags, Business Services can be used in the reporting module to generate reports, but because Business Services understand the system dependencies and relationships they can generate real SLA reports, no need for any manual calculations!
The Opsview Reporting Module allows you to generate a variety of reports. It is an optional extra in Opsview Monitor Pro Edition but is included out of the box in the Opsview Monitor MSP and Enterprise Editions.
When generating reports the data comes from the ODW (Opsview Data Warehouse) database. There are settings within Opsview Monitor that allow you to configure what data is stored into the ODW. You can find the ODW settings from the main menu under Help -> My System then go to the ODW tab.
The “Enable ODW Import” controls the import of basic monitoring information, such as state changes and summarized statistics. These are used in the availability and event reports, and use a relatively small amount of storage space due to the use of summarized and aggregated information.
The “Enable extended import” option allows you to store all performance data returned by plugins which are used by performance and trend type reports. This greatly increases the storage required for the database, as it will store all service check results and performance data points for the specified retention period.
It is worth noting that data is stored to the ODW only from the point that the ODW settings are configured and that a Business Service or Hashtag is created, so if you were to create a Hashtag today you will be able to run a daily report starting from tomorrow.
Notifications are an important way to ensure that users are alerted to events within the monitoring system, Opsview Monitor includes many different notification methods from email to service desk connectors. You can find details of them here.
Opsview Monitor has a number of different options that allow you to scale your system, varying from moving your ODW database onto a separate and dedicated system to optimizing the databases. However, the most notable and useful scalability feature is Distributed Monitoring using Opsview Monitor Slaves.
Opsview Monitor Slaves are an option as part of the Scalability pack in Opsview Monitor Pro Edition but are included out of the box in the Opsview Monitor MSP and Enterprise Editions.
Opsview Monitor Slaves are monitoring collectors that run on a separate machine to the Opsview Monitor Master, the central management system. They run checks and then pass the results back to the Master.
As well as taking some of the load from the Master system, they have a few other very useful features:
Opsview Monitor Slaves can be located within a different network or data center to the Master system; they then just utilize a single channel of encrypted communication, which can be initiated Master to Slave or Slave to Master as required by your environment. This reduces the amount of configuration required to monitor hosts within another network or data center as you do not have to open up multiple firewall rules, as well as having the effect of improving security by reducing complexity.
Network outages between data centers can be a common issue, and monitoring across these links can be unreliable if the network is unreliable or heavily loaded. Opsview Slaves solve these problems, they are able to buffer data during network drops and the checks run locally so will not be slowed down by anything external. Notifications can also be sent directly from Slave systems so that even in the event that the Opsview Monitor Master Server cannot be contacted, your users will still be notified of detected problems.
It is common to implement redundancy in any monitoring system. Opsview has extensive support for both high availability and disaster recovery for the Master system, so why not apply this approach to the distributed Slave systems as well?
Opsview Monitor Slave monitoring systems fully support clustering, allowing you to deploy two or more Slave systems in a group which can cope with the failure of one of its members without interrupting monitoring.