Custom Notification Methods

You may want to use an existing Nagios Core notification script in Opsview Monitor.

Adding and writing your Notification Method Copied

To add this a custom notification method:

  1. Check the Notification script for any dependencies. This may require additional software to be installed on the Opsview Monitor Orchestrator server (and Collector). 2 Test the Notification script. Opsview Monitor provides a way of simulating the environment variables that Nagios Core will set at notification time. If you intend to run this notification on Collector, you should test on those servers too:

    # Test Host
    sudo -u opsview /opt/opsview/coreutils/utils/test_notifications hostproblem /path/to/notificationscript [other parameters]
    
    # Test Service
    sudo -u opsview /opt/opsview/coreutils/utils/test_notifications serviceproblem /path/to/notificationscript [other parameters]
    
  2. Put your script into /opt/opsview/monitoringscripts/notifications/ on the Opsview Orchestrator server, as the opsview user.

  3. Go to Configuration > Notification Methods and click Add New to set the appropriate configuration.

  4. Each User will then have to select this Notification Method to one of their Notification Profiles.

  5. Go to Configuration > Apply Changes to make the new setup live.

  6. Cause a failure to test that the notification is sent.

Name Copied

The name of your Notification Method.

Enable Copied

This determines whether the Notification Method is enabled or not.

Run On Copied

Should the Notification Method execute on the Orchestrator system or Collector systems

Command Copied

Command to run when the Notification Method executes.

User Variables Copied

Comma separated list of variables that must be provided by a user when setting up the Notification Method.

Writing your own notification script Copied

Your notification script should be written to expect any input regarding the notification alert from Nagios Core via environment variables, see Macro Availability Chart.

The only environment variables available for Notification Methods are:

For example, in perl, reference the HOSTNAME variables using:

print "$ENV{NAGIOS_HOSTNAME}\n";

In bash, use:

echo $NAGIOS_HOSTNAME

A useful trick in bash to see all available environment variables is to add at the top of a Notification Method:

{ date; echo "Called with $@"; env; echo; } >> /tmp/env.txt

To distinguish between a service alert and a Host alert, do something like (in Perl):

if ( $ENV{NAGIOS_SERVICEDESC} ) {
# This is a service alert
} else {
# This is a Host alert
}

Global settings should be stored either in the script or via command arguments.

OUTPUT Copied

The environment Variables SERVICEOUTPUT, HOSTOUTPUT, LONGSERVICEOUTPUT, LONGHOSTOUTPUT hold the output from a plugin. The first two hold only the first line of the output, while the remainder is in the LONG variables. Note that the left and right angle brackets (<>) are stripped from the output.

CONTACTGROUPLIST Copied

This environment variable holds all the contact groups that this Host/service belongs to, in a comma-separated list. Contact groups will be of the form:

You can use this to get the list of keyword names that the Host/Service is related to by:

@keywords = grep { s/k\d+_// } (split ",", $ENV{NAGIOS_CONTACTGROUPLIST})

Testing Notification Scripts Copied

As mentioned above, notification scripts can be tested on both the Orchestrator and Collectors by using:

sudo -iu opsview /opt/opsview/coreutils/utils/test_notifications hostproblem /path/to/notificationscript [other parameters]

Some scripts may require extra configuration to test them. For example, to test the VictorOps notification method, ensure the access key is set in the UI and then use the following:

export NAGIOS__CONTACTVICTOROPS_ROUTING_KEY="<routing_key>"
/opt/opsview/coreutils/utils/test_notifications hostproblem /opt/opsview/monitoringscripts/notifications/notify_by_victorops
where the routing key is set as per your VictorOps routing configuration.

This particular notification method logs to /var/log/opsview/opsview.log, but you need to check within each script where logging is sent (in many cases script output is captured in a file located in /tmp/).

["Opsview On-premises"] ["User Guide"]

Was this topic helpful?