There are seven actions that are available from the contextual menu of Host Groups, Hosts and Service Checks:
- Schedule Downtime
- Mass Re-Checks
- Mass Acknowledgement
- Set Host Check Status
- Set Service State
Contextual menu of a Host Group
Contextual menu of a Host
Contextual menu of a Service Check
Downtime provides you with the ability to set 'maintenance windows' within Opsview Monitor, essentially pre-warning Opsview Monitor about potential failures within a given time and date window.
Downtime is typically scheduled when maintenance is set to occur on Hosts, for example Saturday evening 19:00 to 23:00 when patching of the operating systems may occur. By telling Opsview Monitor in advance of the patching on certain Hosts, Opsview Monitor can suppress any Notifications when problems are detected.
Downtime also affects SLAs within the Reports module, as failures during a downtime window will be considered 'scheduled downtime' rather than 'unscheduled downtime'.
Downtime can be set at a Host Group level, which propagates 'downwards' and will thus put all Hosts and Service Checks within the Host Group into a state of Downtime during the determined period. It can also be set at a Host level, thus affecting the specified Host and its Service Checks, or it can finally be set at on a individual Service Check on an individual Host, e.g. 'Apache2' on Host 'www-data' will be updated between 15:00 and 15:30, so you could schedule downtime to prevent notifications.
Note: Because the downtime affects all Hosts and all services within a Hostgroup, the ability to schedule downtime at a Host Group level is only available to a user with the DOWNTIMEALL access. Users with DOWNTIMESOME can set downtime on a per-Host or per-Service Check level (if they have permission).
Re-Checks provide you with the ability to interrupt the regular check interval and force a manual check. For example, if a Service Check runs every 15 minutes, you can use 'Re-Check' to force Opsview Monitor to run the Service Check/Host 'now', instead of waiting for up to 15 minutes to elapse before the Service Check runs again.
Re-Checks can be executed at a Host Group level (thus re-checking all Hosts (Host checks) and Service Checks within the Host Group), at a Host level (thus re-check the Host (Host check) and all of its Service Checks) or at a Service Check level (re-checking just the individual Service Check).
Acknowledgements are available when a Host or a Service Check is in a non-OK state. Acknowledgements provide you with the ability to 'handle' a problem, i.e. tell Opsview Monitor 'I am aware of the problem'. By acknowledging a Service Check/Host in a non-OK state, Opsview Monitor will move the affected items from an 'Unhandled' to a 'Handled' state, which affects the views within the Navigator section of the 'Host Groups, Hosts and Services'.
Acknowledgements are primarily a method of disabling Notifications for a Host or Service Check. It allows a user to add a comment to show the current situation for the given Host/Host Group and is a way of dealing with unplanned problems.
There are two types of acknowledgements:
- Normal: If the Host or Service Check's state changes from a non-OK state to any other state (e.g. from Warning to Critical), the acknowledgement is cleared and notifications will be re-enabled.
- Sticky: Only when the Host or Service Check returns to an 'UP' or 'OK' state will the acknowledgement be cleared and notifications will be re-enabled. This is often useful for when a Host or Service Check is flapping between a WARNING state and a CRITICAL state.
All comments associated with an acknowledgement (sticky or normal) will be cleared when the acknowledgement is removed.
All Hosts that are in an 'UP' state, or Service Checks that are in an 'OK' state, are automatically considered 'handled' and cannot be acknowledged.
Set Service Status can be used to forcibly change the state of a Host or Service Check at a Host Group, Host or Service Check level. For example, you may wish to test that Notifications are working for a key Service Check. You could either amend the Service Check and wait for it to fail or you could use 'Set Service Status' to forcibly change the service check to 'CRITICAL', thus triggering the notifications.
Note: in order to force the Notification to trigger in this example, a number of 'Set Service Status' changes must be submitted within the 'Retry Interval' to order to pass the configured 'Max Check Attempts' limit (by default, Max Check Attempts is three and the Retry Interval is one minute).
Comments can also be added when a Service Check status is changed, e.g. 'Changing to critical to test Notifications'. As the Service Check is changed to CRITICAL in our example, the 'Retry interval' will kick-in and the Service Check will be re-checked automatically (thus likely to return to an OK state within 1 minute).
Notes can be entered for Host Groups, Hosts and Service Checks using the contextual menu. Notes are free-text; a WYSIWYG editor is provided where you can add notes to items within Opsview Monitor for future reference, e.g. adding a note against a router with information about VLANs, routing tables, etc.
'Investigate' is an option that is available in the contextual menus of Hosts and Service Checks. When you click on 'Investigate' a modal window will appear with all the relevant information for the Host or Service Check. The concept behind 'investigate' is to provide you with a single view into every facet of the Host or Service Check selected, including event information, graphs, testing, notifications and more.