Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Related DocumentationVersion of up.time affectedAffected Platforms
This article is part of a series:
\n \n
\n Part 1 - Creating Custom Service Monitors in up.time
\nPart 2 - Creating Custom Service Monitors with Retained Data Collection
\n Part 3 - Creating Plug-in Service Monitors in up.time
\n
AllAll
\n \n

\n \n

Article Contents \n

\n \n \n \n
\n

Overview
\n \n

\n \n

Custom service monitors with retained data tracking expand on \nthe basic Custom service monitor by allowing you to retain and graph \nhistorical trending information returned from your custom script. This \nenables you to store up to 10 custom application or business metrics \nper monitor within up.time just like system performance metrics \nreturned by the up.time agent. This article builds on the scripts and \nknowledge that were developed in a previous \narticle. Take some time to review the previous article before \ncontinuing.

\n \n

Example graph produced using a custom \nservice monitor with retained data.
\n \n
\n \n

\n \n
\n

Formatting your monitoring \nstation script for retained data tracking
\n \n

\n \n

To use a custom script with retained data with up.time, you \nmust change the output format produced by your script. All of the rules \nfound in a regular custom service monitor still apply with a few slight \nmodifications, as detailed below: \n

\n \n
    \n \n
  1. The monitoring station script must return a single number \n(decimal or integer) per line -- one line for each metric that you want \nto up.time to retain. You can have a maximum of 10 lines retained. The \nexample script output shown below retains the values '10.5' and '99' as \ntwo distinct graphable trends within up.time: \n

    > check_temp.sh
    \n \n10.5
    \n \n99
    \n \n

    \n \n
  2. \n \n
  3. The output must be in numeric format; you cannot have text \noutput. This enables the service monitor to perform all threshold \nchecking within up.time instead of having your script determine \nthresholds and return an outage message in text format.
  4. \n \n
  5. The script must exit with a success status (0), unless \nthere has been a problem when the script is run or if you want to force \na status for the service monitor.
  6. \n \n
  7. The script must accept the hostname of the agent system as \nthe first argument. up.time will automatically add this argument to the \narguments passed to your script.
  8. \n \n
  9. In general, you do not need to change to your existing \nagent side script or configuration in order for your service monitor to \nretain performance metrics.
  10. \n \n
\n \n
\n

Changing the check_temp script \nfor retained data
\n \n

\n \n

Using the check_temp.sh \nscript as a basis for this example, you can easily change the script to \nfit within the context of a custom service monitor with retained data. \nTo do this, you must make the following changes to the script:

\n \n
    \n \n
  1. Remove the logic included within the script to check \nthe temperature and humidity thresholds.
  2. \n \n
  3. The output that is produced by the script will be changed \nto output the current temperature level on a single line followed by \nthe current humidity. Here is an example of how our output and command \nformat will change. \n

    Previous Format - For a \nregular custom service monitor.
    \n \n> ./check_temp.sh test-agent 9998 temp 60 80
    \n \nWARNING - temperature is 64.5 on test-agent
    \n \n> ./check_temp.sh test-agent 9998 rh 25 30
    \n \nCRITICAL - humidity is 32.8 on test-agent
    \n \n

    \n \n
    \n \n

    New Format - For a \ncustom service monitor with retained performance data.
    \n \n> ./check_temp.sh test-agent 9998
    \n \n64.5
    \n \n32.8
    \n \n

    \n \n
  4. \n \n
\n \n

To produce the output listed above, you must edit the script \nso that it looks like the following example:
\n \n

\n \n

#!/bin/sh
\n \n
\n \n# This script takes the following arguments:
\n \n# check_temp.sh hostname port
\n \n# Example execution:
\n \n# ./check_temp.sh my-agent 9998
\n \n
\n \n# This script can be placed anywhere on the monitoring station system \nas long as it is
\n \n# executable by the uptime user.
\n \n
\n \n#First, collect our arguments
\nAGENT=$1
\nPORT=$2
\n
\nTMPFILE=/tmp/$$.temp
\n
\n# now use the info above to contact our agent, store the output in a \nfile for parsing
\n \n`echo -n rexec secretpassword /opt/uptime-agent/my-scripts/show_temp.sh \nmy-arguments | /usr/local/uptime/bin/netcat $AGENT $PORT > $TMPFILE`

\n \n

Note: If you are using agentcmd instead of netcat, replace netcat with agentcmd in the command above. For example:

\n \n

`echo -n /opt/uptime-agent/my-scripts/show_temp.sh my-arguments | /usr/local/uptime/scripts/agentcmd -p $PORT $AGENT rexec secretpassword > $TMPFILE`

\n \n

For more information on the syntax used with agentcmd, see this Knowledge Base article.

\n \n

\n# we have the output from the agent. If it is ERR that means there was \na problem running the script on the agent
\n \n`grep ERR $TMPFILE`
\n \nif [ $? -eq 0 ]
\nthen
\necho "Could not execute agent side script!"
\n \n# by exiting with a 2 we are forcing a CRIT service outage
\n \nexit 2
\nfi
\n
\n \n# in this script we don't need to check thresholds or determine which information to check
\n# we just need to reformat the agent side script output slightly so that only numerical info is displayed
\n# we do this by trimming off the first word returned on each line from the agent, leaving just the numbers
\n# and printing that to screen, up.time will handle the rest
\n \n
\nawk '{print $2}' $TMPFILE
\n
\nexit 0
\n

\n \n
\n

Adding Custom Service Monitor \nwith Retained Data to up.time
\n \n

\n \n

Next, add your custom service monitor with retained \nperformance metrics to the up.time Web interface using the same process \nthat you would use to add a standard custom service monitor to up.time. \nThe Custom with \nRetained Data monitor option is found in the List Other Monitors \nsection of the Add New \nService Instance page.

\n \n

The Custom with Retained Data service monitor \ntemplate has the following monitor-specific settings:
\n \n
\n \n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Option NameDescriptionExample
Script NameThe script name \nis the path to your monitoring station script, this is the script that \nup.time will execute when running this service monitor. Be sure to use \nthe complete path wherever possible and that the path is to a locally \nmounted volume. For Windows script paths you must use UNIX style \ndirectory separators (/ instead of ) and also place double quotes \naround the entire script nameUNIX/Linux \nExample:
\n \n/usr/local/uptime/check_temp.sh
\n \n
\n \nWindows Example:
\n \n"C:/my scripts/check_temp.bat"
ArgumentsThese are the \narguments that you would like up.time to pass into your monitoring \nstation script. No arguments are required but please be aware that \nup.time will automatically include the selected hostname as the first \nargument to your script.temp 60 80
Variable 1-10 WarningThis 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 thresholdOutput \ncontains: "warning"
Variable 1-10 CriticalThis is the \ncritical threshold used against the output returned from your \nmonitoring station script. This is a numeric comparison. You must \nselect both a comparison method and a threshold value to enable the \ncritical level thresholdOutput \ncontains: "critical"
Retained Data TrackingThis check box \ndetermines if up.time will not only check the variable for threshold \nviolations but will also retain the returned values for graphing at a \nlater time. In most cases you should check this box, without it data \nfor the indicated variable will not be retained for graphing.N/A
\n \n

Based on the settings used in the example monitoring station script, configure the monitor with the following setting:

\n \n
    \n \n
  • Enter a name and description for the monitor.
  • \n
  • Select a host from the dropdown menu. Be sure to select the same host that your agent side script is on
  • \n
  • In the Script Name field, \nenter the path to the custom script on your monitoring station. On Windows systems be sure to use UNIX style / instead of and put quotation marks around your path. For example: "C:/my files/check_temp.bat" \n
  • \n
  • In the Arguments field, \nenter the arguments for the script. up.time adds the agent name as the first argument automatically so do not include it.
  • \n
  • Select contains from the Warning dropdown and enter WARNING as the search text.
  • \n
  • Select contains from the Critical drop down and enter CRITICAL as the search text.
  • \n
  • Complete the remainder of the monitor template as you would for a normal service monitor.
  • \n
\n \n

Example monitor configuration

\n \n

The image below illustrates a sample monitor configuration. This service monitor will indicate a WARN or CRIT whenever \nthe monitoring station custom script returns WARNING \nor CRITICAL in its output.

\n \n

  • No labels