IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
IT Monitoring for Networks, Applications, Virtual Servers and the Cloud
The Service Checks tab is designed to give you the ability to:
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 level down.
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 Template.
The right-hand section of the Service Checks tab is 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:
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:
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. You will need 'TESTALL' role access to be able to use this functionality.
Example ‘Test Service Check’ output.
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’, essentially).
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 arguments’ box.
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:
-H $HOSTADDRESS$ -u %MYSQLCREDENTIALS:1% -p %MYSQLCREDENTIALS:2% --metricname=Bytes_received
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 drawer.
As covered earlier in this section, the Exceptions drawer will 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 are:
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.