This section explains how to add, configure and analyze Hosts and Host Groups.
This includes notions such as Hosts, Host Groups, Autodiscovery, Host Check Commands and the Navigator.
This document explains the concept of Hosts and Host Groups, explains what a Host is, how to configure a Host, how to configure a Host Group hierarchy, and how the Host Check Commands work.
After reading this User Guide, Users should be able to create their own Hosts, arrange them logically in a Host Group topology and have the ability to customize and fine-tune various elements of the Host. This includes adding variables, changing the date and time the Host is checked and more.
Opsview Monitor uses a well-founded monitoring terminology which includes:
- You can choose to have a Host Group which contains sub Host-groups, i.e. you have a Host Group called 'Linux Servers'. This Host Group contains two Host Groups called 'Ubuntu Servers' and 'Red Hat Servers'. The aforementioned Hosts then live within these two 'sub' Host Groups.
- Note: A Host Group can contain EITHER sub Host Groups OR Hosts; not a combination.
- Host: In Opsview Monitor, a Host is defined as 'an autonomous computing device, such as (but not limited to), a server, virtual server, a collector server, database server, workstation, PC, network device, storage device, sensor, tablet or mobile device.' Essentially a Host is a logical endpoint, meaning a Host could be your VMware Host, your Oracle database, a Cisco switch or more. It is very flexible.
- Host check: A Host check is what Opsview Monitor uses to determine the 'Host status', i.e. is the Host 'UP', 'DOWN' or 'UNREACHABLE'.
- Generally, the Host Check Command is ping, i.e. can we ping the router, switch, server, website, etc. However, in the likely scenario ping is blocked there are a multitude of other Host Check Commands that can be used to attempt to reach the Host via its given address. For example, your Host may be a website, therefore you can use a Host Check Command that checks for a response on port 80. If your webserver, i.e. Apache2 process, is not running, then the host check command will show the host as 'DOWN', even though the host may be UP, but the Apache2 service is not running.
- Host Group: A Host Group is a logical container where you can choose to group a series of Hosts together. For example, you may have a Host Group called 'Linux Servers' which contains 15 Hosts; each Host being an Ubuntu or Red Hat server.
These terms are used in a hierarchy which is common across thousands of monitoring systems throughout the world. By default, Opsview Monitor ships with a simple hierarchy of:
In the product this appears as:
Here we can see the default Host Group, 'Monitoring servers', and the default Host, 'opsview' within.
In larger environments, most customers generally choose to segment their Hosts into one of four ways:
By department ' A top-level Host Group for the department, e.g. 'Finance', and then sub level Host Groups if required, e.g. 'Oracle applications'.
Example: Host Group hierarchy segmented by department, Hosts in orange
By customer ' For those reselling Opsview Monitor, a Host Group per customer may be preferable, e.g. 'Customer A -> Data Center A >CustomerA-Host1, CustomerA-Host2,..'.
Example: Host Group hierarchy segmented by customer, Hosts in orange
By technology ' Some administrators choose to group by technology, e.g. 'Servers > Linux Servers > Ubuntu Servers > Ubuntu1, Ubuntu2,...'.
Example: Host Group hierarchy segmented by technology, Hosts in orange
By location ' Finally, administrators may choose to group their Hosts logically using location (Data centers, racks, etc). For example you may have 'Data Center A > Rack 2 > HostA, HostB, ..'.
Example: Host Group hierarchy segmented by location, Hosts in orange
In our example below, we have chosen to configure our Host Groups logically by their technology:
There are numerous reasons why administrators choose to configure Host Groups in a logical hierarchy. Host Groups are used extensively within Opsview Monitor for various core functions, as detailed below.
You can choose to permit Users of Opsview Monitor to view only certain Hosts by configuring their Role to only have the ability to view a given Host Group.
For example, in the scenario earlier where we explained a potential logical topology based on Customers, you can say 'Anyone in the 'Tims Tyres' role can only see Hosts added to 'Customers > Tims Tyres'. This is great for security as it means that any Host placed outside of that group is invisible to users of that Role.
It also means that if you add more Hosts to the 'Tims Tyres' Host Group, then no extra reconfiguration is required.
You can also choose to use Host Groups as part of Notifications. For example, you can configure a Notification Profile so that the users of Tims Tyres only get emails when there are failures on Hosts within the 'Tims Tyres' Host Group only.
Covered in this Guide in more detail, Actions allow you to perform a function against a given Host Group, Host or Service Check. For example, if you are performing maintenance against one or more Hosts you should put the affected Hosts into 'downtime' for the given period. This prevents Notifications being sent for outages which are occurring as part of the maintenance; in essence, downtime tells Opsview Monitor 'Hey, we're doing something so if problems happen it's likely because of that, so don't email us!'. Downtime is covered in a separate area of the User Guide.
From a Host Group perspective, instead of putting each Host into downtime individually, you can choose to put an entire Host Group into a state of downtime, i.e. the entire of Tims Tyres infrastructure will be offline this weekend so let's go ahead and schedule some downtime for that Host Group (and thus everything in it) from 6:00 pm on Friday until 8:00 am Monday.