Page History
...
When this is triggered via the 'Test Service Monitor' button, you would see something like this:
The first thing you'll likely notice here is that the Monitor monitor has set it's its Status to OK, which is the default state for a service monitor that's run successfully, as long as none of it's its threshold comparisons are triggered. The 'message' Message line shows use that the process returned a valid status, which is then followed by the output from the plugin monitor, i. iee. 'custom1 uptime_core is stopped MON Role'.
You may wonder where the 'custom1' string is coming from as it's not in the example output of the agent side script above. This is inserted by the rcs.php and used to mark that the output from the agent script should link up with the 'custom1' variable from the XML. Which you can see on the next line 'Output ' where 'custom1' has been is replaced with that variable's Short-Description also form short description also from the xml. The next line is an example of Uptime Infrastructure Monitor UIM attempting parse the second line of output from our agent script into a variable called 'MON' but because this isn't defined in our xml file, it won't be available for comparisons within the GUI. The final line here is the Response time value, which is the special timer mentioned above.
The general take-away takeaway from this test service monitor example is that when Uptime Infrastructure Monitor UIM is able to parse /and understand the output from a script, the matched up variables will be are listed line by line after the message. With the ' name ' of the variable replaced by it's its short description. If you don't see your output variable listed like this, then double check the names of your output variables and how the script itself is returning its output.
...