Related Documentation | Version of up.time affected | Affected Platforms |
This article is part of a series: Part 1 - Creating Custom Service Monitors in up.time Part 2 - Creating Custom Service Monitors with Retained Data Collection Part 3 - Creating Plug-in Service Monitors in up.time | All | All |
Article Contents
Overview
Custom service monitors with retained data tracking expand on the basic Custom service monitor by allowing you to retain and graph historical trending information returned from your custom script. This enables you to store up to 10 custom application or business metrics per monitor within up.time just like system performance metrics returned by the up.time agent. This article builds on the scripts and knowledge that were developed in a previous article. Take some time to review the previous article before continuing.
Example graph produced using a custom service monitor with retained data.
Formatting your monitoring station script for retained data tracking
To use a custom script with retained data with up.time, you must change the output format produced by your script. All of the rules found in a regular custom service monitor still apply with a few slight modifications, as detailed below:
> check_temp.sh
10.5
99
Changing the check_temp script for retained data
Using the check_temp.sh script as a basis for this example, you can easily change the script to fit within the context of a custom service monitor with retained data. To do this, you must make the following changes to the script:
Previous Format - For a regular custom service monitor.
> ./check_temp.sh test-agent 9998 temp 60 80
WARNING - temperature is 64.5 on test-agent
> ./check_temp.sh test-agent 9998 rh 25 30
CRITICAL - humidity is 32.8 on test-agent
New Format - For a custom service monitor with retained performance data.
> ./check_temp.sh test-agent 9998
64.5
32.8
To produce the output listed above, you must edit the script so that it looks like the following example:
#!/bin/sh
# This script takes the following arguments:
# check_temp.sh hostname port
# Example execution:
# ./check_temp.sh my-agent 9998
# This script can be placed anywhere on the monitoring station system as long as it is
# executable by the uptime user.
#First, collect our arguments
AGENT=$1
PORT=$2
TMPFILE=/tmp/$$.temp
# now use the info above to contact our agent, store the output in a file for parsing
`echo -n rexec secretpassword /opt/uptime-agent/my-scripts/show_temp.sh my-arguments | /usr/local/uptime/bin/netcat $AGENT $PORT > $TMPFILE`
Note: If you are using agentcmd instead of netcat, replace netcat with agentcmd in the command above. For example:
`echo -n /opt/uptime-agent/my-scripts/show_temp.sh my-arguments | /usr/local/uptime/scripts/agentcmd -p $PORT $AGENT rexec secretpassword > $TMPFILE`
For more information on the syntax used with agentcmd, see this Knowledge Base article.
# we have the output from the agent. If it is ERR that means there was a problem running the script on the agent
`grep ERR $TMPFILE`
if [ $? -eq 0 ]
then
echo "Could not execute agent side script!"
# by exiting with a 2 we are forcing a CRIT service outage
exit 2
fi
# in this script we don't need to check thresholds or determine which information to check
# we just need to reformat the agent side script output slightly so that only numerical info is displayed
# we do this by trimming off the first word returned on each line from the agent, leaving just the numbers
# and printing that to screen, up.time will handle the rest
awk '{print $2}' $TMPFILE
exit 0
Adding Custom Service Monitor with Retained Data to up.time
Next, add your custom service monitor with retained performance metrics to the up.time Web interface using the same process that you would use to add a standard custom service monitor to up.time. The Custom with Retained Data monitor option is found in the List Other Monitors section of the Add New Service Instance page.
The Custom with Retained Data service monitor template has the following monitor-specific settings:
Option Name | Description | Example |
Script Name | The script name is the path to your monitoring station script, this is the script that up.time will execute when running this service monitor. Be sure to use the complete path wherever possible and that the path is to a locally mounted volume. For Windows script paths you must use UNIX style directory separators (/ instead of ) and also place double quotes around the entire script name | UNIX/Linux Example: /usr/local/uptime/check_temp.sh Windows Example: "C:/my scripts/check_temp.bat" |
Arguments | These are the arguments that you would like up.time to pass into your monitoring station script. No arguments are required but please be aware that up.time will automatically include the selected hostname as the first argument to your script. | temp 60 80 |
Variable 1-10 Warning | This is the warning threshold used against the output returned from your monitoring station script. This is a numeric comparison. You must select both a comparison method and a threshold value to enable the warning level threshold | Output contains: "warning" |
Variable 1-10 Critical | This is the critical threshold used against the output returned from your monitoring station script. This is a numeric comparison. You must select both a comparison method and a threshold value to enable the critical level threshold | Output contains: "critical" |
Retained Data Tracking | This check box determines if up.time will not only check the variable for threshold violations but will also retain the returned values for graphing at a later time. In most cases you should check this box, without it data for the indicated variable will not be retained for graphing. | N/A |
Based on the settings used in the example monitoring station script, configure the monitor with the following setting:
Example monitor configuration
The image below illustrates a sample monitor configuration. This service monitor will indicate a WARN or CRIT whenever the monitoring station custom script returns WARNING or CRITICAL in its output.