IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
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 Operating system and include all of the packages and configuration for a complete setup of each of the different Opsview Monitor Editions.
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 I had one server running ESXi which hosted 5 Virtual Machines my total host count would be 6 (1 for the ESXi server and 5 Virtual Machines).
Opsview Monitor licencing 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 hosts as you require.
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 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 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 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 organisation. 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.
A lot 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.
The Opsview Monitor Business Service Module (BSM) 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 I had a clustered pair of Exchange servers I can add them both to a Component and then set a 50% operational zone, meaning I only require either one of the two up at any one time for this part of my Business Service to be operational. I 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 Service 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 setting 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” option is for the basic monitoring information, Ok or critical status and for availability statistics. These are used in the availability and event reports.
The “Enable extended import” option allows you to store all performance data returned by plugins which are used by performance and trend type reports.
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 tomorrow.
Alerts are an important way to ensure that users are alerted to events within the monitoring system, Opsview monitor includes many different notification methods from Emails to service desk connectors. you can find details of them here.
Opsview has a number of different options that allow you to scale your system, varying from breaking out your ODW database onto another system to optimising the databases. However, the most notable and useful scalability feature are 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 very useful features: