The Service Checks tab is designed to give you the ability to:
Add Service Checks to a Host.
Modify Service Checks on a Host basis, i.e. use different arguments just for this Host.
Omit Service Checks that have been inherited via a Host template; i.e. ‘we don’t
want this service check on this Host but we want the rest from the Host
Test Service Checks against a Host before submitting the change and reloading.
The left-hand section of the Service Checks tab displays the service
check ‘tree’. Service Checks reside within ‘Service Groups’ (covered in a
separate section), e.g. the checks visible above, such as ‘CPU statistics’,
live within the service group ‘OS – Base Unix Agent’. The algorithm behind the
tree structure creation uses the hyphens as the separator, therefore ‘OS – Base
Unix Agent’ becomes ‘OS’ at the top level, and ‘Base Unix Agent’ at the 2nd
In the tree on the
far right of the Service Checks’ row (the items with the check boxes) is the
location where one of two icons will potentially be displayed. These icons
depict whether this Service Check is inherited from a Host template or whether
it was originally inherited from a Service Check and has since been ‘omitted’,
i.e. ‘don't apply this Service Check to this Host’. This ‘omit’ option is
toggled by using the ‘Remove Service Check from Host Template’ option within
the Service Check, and only becomes visible when the Service Check is checked in
the left hand section.
A Service Check inherited from ‘OS – Unix
Base’ Host template, that has been omitted, i.e. won't be applied to this Host.
A Service Check inherited from
‘OS – Unix Base’ Host template.
If a Service Check is
inherited from a Host template yet isn’t ‘checked’ in the left-hand section, the
‘Exceptions’ section will not be editable and the ‘Remove Service Check from Host
Template’ toggle button will not be visible. To edit these items, checking the box next to the Service Check tells Opsview Monitor to look at
this section for information on this Service Check instead of the Host
The right-hand section of the Service Checks tabis populated with
information and options relevant to the selected Service Check and is commonly
referred to as the ‘Service Check information panel’.
When no Service Check
is selected, this section will contain a message informing you to select a
Service Check first.
Service checks tab without a
service check selected.
When a Service Check
is selected and checked in the left-hand tree panel, the Service Check
information panel will populate with relevant data:
Example Service Check
The ‘Service Check
information’ panel contains:
Service Check name
Service Check description
This information is
non-editable from within the Service Check info panel and is only included in
this view for an information perspective.
The ‘Service Check
information’ panel also contains:
Plugin and Macro help buttons
Service Check: arguments
Test Service Check: button
The ‘test service check button’, ‘plugin and macro help’ and ‘test service check: arguments’ sections
are designed to provide the ability to test a Service Check against the
relevant Host before submitting the changes (‘Submit Changes’) and reloading
Opsview Monitor. By proving the Service Check will perform as expected, i.e. work correctly
before a reload takes place, will save hours of time.
Example ‘Test Service Check’
The ‘Plugin’ help button will load a new
modal window displaying the ‘Help file’ for the plugin. The ‘Macro’ help button will load a new
modal window displaying all of the available system macros (system ‘variables’,
Example plugin help output.
Example macro help output.
The ‘test Service Check arguments’ input box
allows for the modification of the arguments before they are passed to the
plugin to be executed within the ‘Test Service Check’ box. Here you can modify
items relevant to the Service Check, i.e. a different port, file name, etc.
Example ‘Test Service Check
The ‘Variables’ drawer contains all
variables that the Service Check may be using. ‘Variables’ are covered in great
detail within their relevant User Guide section; however, in essence they act
like standard computer science ‘Variables’, in that you can configure ‘-p %PORT%’
instead of ‘-p 9200’ for an Elasticsearch Service Check’s arguments. The
benefit of this is that by using a Variable instead of hard coding the port, you
can apply the Service Check to hundreds of Hosts and simply add the ‘%PORT%’ Variable to the Hosts which don’t have Elasticsearch on port 9200.
If a Service Check requires a Variable in order to successfully work, then the Variable will be
listed within the ‘Variables drawer’. In the example Service Check below we are
applying a Service Check to monitor the number of Bytes received for a MySQL
database. The syntax for this Service Check is:
This means that the
username field (-U) and the password field (-P) are located within the
%MYSQLCREDENTIALS% attribute. By
default, the Variables drawer will be empty. It will only be populated with
the Variables required once you have pressed the ‘Test’ button:
Example of Variables drawer where there are
either no variables required, or the ‘Test’ button has not been pressed.
Example of a Variables drawer where the test
button has been pressed and %MYSQLCREDENTIALS% is required.
If these Variables
are not populated with global defaults (Settings > Variables), then the
Service Check will fail as there is no means to log in to the MySQL database
in order to monitor it. If that is the case then you will need click the ‘Add’
button next to the Variable, which will navigate to the ‘Variables’ tab and add
a new Variable as below:
Here you will need to
enter a value (not relevant to this Service Check so enter anything) and click
‘Save’. Once saved the ‘Host variable details’ panel will populate. Here you can
now check both ‘Override username’ and ‘Override password’ and enter the correct
login information for this database.
Once the correct
information is added, navigate back to the Service Checks tab and click
‘Test’ again and if you have added the correct credentials, the Service Check should now successfully work:
Example ‘Test Service Check’
output using the correct Variables.
You can now safely
submit the changes (‘Submit Changes’) and reload Opsview Monitor knowing that the
Service Check will work post-reload.
If you wish to change the actual plugin arguments
themselves (i.e. add a warning/critical level (-w/-c) to the Service Check),
then you can do so via the Exceptions
As covered earlier in
this section, the Exceptions drawerwill
not be modifiable until the Service Check is checked in the left-hand tree pane.
Once the check is checked, the Exceptions drawer should look similar to the one below:
The three options
Exception: change the arguments of the Service Check regardless of Time Period.
Timedexception: Change the arguments of
the Service Check to be what is entered in the text box, but only change the
arguments during the chosen Time Period.
Eventhandler: Override the Service Check’s Event Handler with a custom option.
For the ‘MySQL Bytes
Received’ Service Check you may wish to add a ‘-w’ and ‘-c’ option, e.g. if the
number of Bytes received is over ‘X’ set the status to WARNING, and over ‘Y’
set the status to CRITICAL. You can choose to do this by selecting ‘Exception’
and modifying the arguments, using the ‘Plugin Help’ modal for direction on how
to modify these arguments:
When we next run the
‘Test Service Check’, the command run will be modified to use the arguments
specified here instead of the ‘default’ arguments:
The ‘Timed Exception’ option
works exactly the same, however the defined arguments will not be ‘injected’
into the Service Check until the relevant time period begins.