Hosts, Host Groups, and Host Check Commands
This section explains the concept and configuration of Hosts, Host Groups, Host Group hierarchy and Host Check Commands.
You will then be able to create and fine tune your own Hosts monitoring as well as arranging them logically in a Host Group topology. This includes adding variables, changing the date and time the Host is checked and more.
Opsview Cloud uses a well-founded monitoring terminology which includes:
- Host — In Opsview Cloud, a Host is defined as ‘an autonomous computing device, such as a server, virtual server, a collector server, database server, workstation, PC, network device, storage device, sensor, tablet, mobile device, etc.’ 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 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. You can also 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.
NoteA Host Group can contain EITHER sub Host Groups OR Hosts; not a combination. The lowest level contains Hosts only.
- Host check — A Host check is what Opsview Cloud uses to determine the ‘Host status’, i.e. is the Host ‘UP’, ‘DOWN’ or ‘UNREACHABLE’.
- Host Check Command — this is generally a 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.
These terms are used in a hierarchy which is common across thousands of monitoring systems throughout the world. By default, Opsview Cloud 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:
A top-level Host Group for the department, e.g. ‘Finance’, and then sub level Host Groups if required, e.g. ‘Oracle applications’.
For those reselling Opsview Cloud, a Host Group per customer may be preferable, e.g. ‘Customer A -> Data Center A >CustomerA-Host1, CustomerA-Host2.
Some administrators choose to group by technology, e.g. ‘Servers > Linux Servers > Ubuntu Servers > Ubuntu1, Ubuntu2,…’.
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, ..’.
You can choose to allow users of Opsview Cloud 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 Cloud ‘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.