There are numerous
reasons why administrators choose to configure Host Groups in a logical
Groups are used extensively within Opsview Monitor for various core functions, as detailed
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
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 lets 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.