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.

Overview Copied

Opsview Monitor uses a well-founded monitoring terminology which includes:

• Host — In Opsview Monitor, 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.

Note

A 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 Monitor 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 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’.

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.

By technology

Some administrators choose to group by technology, e.g. ‘Servers > Linux Servers > Ubuntu Servers > Ubuntu1, Ubuntu2,…’.

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, ..’.

Access control Copied

You can choose to allow 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.

Notifications Copied

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.

Actions Copied

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.