ITRS Opsview Cloud Documentation

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:


A Host Group can contain EITHER sub Host Groups OR Hosts; not a combination. The lowest level contains Hosts only.

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:

Host group hierarchy

In the product this appears as:

Host Group navigation

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

Host group by deparment

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.

Host group by customer

By technology

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

Host group by technology

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

Host group by location

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.

["Opsview On-premises"] ["User Guide"]

Was this topic helpful?