Submit a ticketCall us

Get a crash course on Network Monitoring delivered right to your inbox
This free 7-day email course provides a primer to the philosophy, theory, and fundamental concepts involved in IT monitoring. Lessons will explain not only how to perform various monitoring tasks, but why and when you should use them. Sign up now.

Home > Success Center > Server & Application Monitor (SAM) > SAM Custom Template Guide > Best practices for SAM templates

Best practices for SAM templates

SAM template creation includes more than just adding and configuring component monitors. These best practices and tips and tricks help you create, customize, and monitor component monitors and templates without running into gotchas.

Learn more about performance enhancements, testing, and scripting.

Performance enhancements

Modify the polling frequency for performance

Depending on the lengthy calls and amount of data pulled for a monitor, you may want to modify the frequency. For script monitors you may need to only run the script once per day, per week, or other frequency. For example, when comparing MIBs using the SolarWinds MIB Database template, you may only need to run the comparison once a day, a week, or every couple of months.

Extend the polling timeout for long calls

For scripts with lengthy calls for large amounts of data, extend the polling timeout. The default 300 seconds may not be long enough for script processing to complete. If the call may take more time, especially during peak times, increase the timeout to give the system time to complete the call. For example, for MIB database comparison scripts using the SolarWinds MIB Database template, multiple files are called, downloaded, and compared to return status messages and complete specific actions.

Enhance latency and performance by pulling multiple metrics per template

When executing script component monitors in a template, SAM affects performance and latency making calls to a target server. Complete calls for up to 10 metrics per script to reduce the number of calls, increasing performance. Depending on the size and processing of scripts, balance scripts and lengthy calls across multiple instances of a script monitor.

Scripts, monitor, and template testing

Check credentials and server permissions for scripts

Verify you have the correct credentials with assigned account permissions to execute scripts on the Orion Web Console and target server. Issues with scripts tend to be with credentials. The script monitors may provide fields for credentials, or you may need to provide credentials in the script code, arguments, or command line. Test the script in SAM prior to verify credentials and access.

Test scripts before monitoring

When adding and configuring script component monitors, you need to test the script. When the test completes, SAM registers each returned metric as a numbered output in the Orion SQL Database. You can configure the display of collected metrics and values through the component monitor. Each script monitor supports up to 10 different outputs.

Receive accurate node status

Until tested, scripts and component monitors return an initial unknown status. After testing, polling returns accurate application status.

Script best practices

Use code comments

Code comments help document the intent for code, decisions made, and to track changes. SolarWinds recommends using code comments to keep detailed steps and responses in your code. If additional administrators need to work in the script monitors, the comments provide context for the code.

# for a comment per line.
For lengthy comments per code section.

Do not use positional parametrization

In the command line for executing scripts, always add the parameter per value. Do not assume the position of data in the command dictates the parameter. For example, use -h for hostname.

Use a header for writing multiple scripts

Create a header in your code to reuse throughout your scripts. The header could include example code and code comments for:

  • A listed of exit codes
  • Set variables for return metrics commonly used in your scripts
  • Use code to determine if you are testing code on the target server or the Orion system

    For example, the following PowerShell code returns a message identifying if the server is a test system or the Orion server:


    Additionally, you could add a step to save the code if not on the Orion server.

Use SolarWinds macros

When using SolarWinds macros, consider assigning them to named variables in your scripts.

The following SolarWinds macros are available for Linux/Unix, Nagios, Windows Script, and PowerShell script monitors:

  • ${USER}
  • ${PORT}
  • ${Node.SysName}
  • ${Node.Caption}
  • ${Node.DNS} - Use this instead of ${IP}.
  • ${Node.ID}
  • ${Component.ID}
  • ${Component.Name}
  • ${Application.Id}
  • ${Application.Name}
  • ${Application.TemplateId
  • ${Threshold.Warning}
  • ${Threshold.Critical}
  • Node Custom Property Macros ${Node.CustomPropertyName}
  • Application Custom Property Macros ${Application.CustomPropertyName}

For agent monitored nodes, use the macros ${Node.SysName} and ${Node.DNS}. The ${IP} may return a loopback IP before polling starts.

Report status through exit codes

Scripts must report their status by exiting with the appropriate exit code. The exit code is used to report the status of the monitor, displayed in the Orion Web Console.

To correctly create this component monitor, you must first return an exit code which results in an Up (0), Warning (2), or Critical (3) status. When one of these exit codes is received the appropriate dynamic evidence table structure is created and all further exit codes are handled correctly. If the component only returns Down (1) or Unknown (4) on first use, the appropriate dynamic evidence table structure is not created appropriately.

You must test the component monitor after entering the script to properly calibrate the monitor, generate tables, and verify correct communication between the target node, SAM, and the template.

  • 0 - Up
  • 1 - Down
  • 2 - Warning
  • 3 - Critical
  • Any other value - Unknown, for example 4

Multiple options for returning exit code and message

You can return one of multiple options for exit codes and messages using IF/ELSE or case statements for your scripts.

Use error trapping to capture issues

Using error trapping code such as try/catch blocks help capture and report errors. These blocks provide better reporting of an error with detailed information for the issue.

Last modified
12:33, 9 May 2017