Welcome to docs.opsview.com

Notification Methods

This provides a list of notification methods that you can use in Opsview.

Opsview is shipped with two by default:

  • Email - where you can send emails
  • RSS - for an RSS feed of notifications. More information here

If there are any contact variables that need to be set, then each contact needs to configure their variables in order for the notification to work (for instance, to use email, each contact has to define their email address).

You can activate as many notification methods as you like.


The name of the notification method. This does not have to be unique, but you are advised to keep it unique for sanity!


You can disable the notification method from being displayed in the contact or notification profile pages.

If you disable the notification method, then all contacts will have this notification method removed.

If there are contacts that still use the notification method, this will get listed when you disable it.

Run On

You can specify whether the notification method is run on:

  • master
  • slave

This option is only shown on systems with slaves configured. If you select Slave and the host that wants to send a notification is monitored by the master server, then the notification will be sent from the master server.

With Opsview < 3.9.0, the options are:

  • the master
  • the monitoring server

A monitoring server is the slave node that the host is monitored by. However, it is possible to have a master act as the monitoring server - especially so in single node environments.

In the diagram above, the monitoring server for host H2 is the master server M. Host H1's monitoring server is the slave S1 and host H3 is monitored by slave S2. Host H4's monitoring server is slave S3.

This is important to decide because it could be possible that results are lost between the slave and the master in a network failure. However, there may be firewall restrictions to running a notification from a slave.

Note: The advantage of running notifications from a slave is that it is autonomous of the master. However, the slave may not do parent/child suppression if the parent of a host is on a different slave - this is particularly true if you are using a slave cluster. You have to send notifications from the master if you want the full suppression facilities as only the master has a complete view of all your hosts.

Note: If a service is monitored by a slave but the notification method is set to the master, then UNKNOWN states will not be notified on. This is because in a distributed environment, if a slave fails, the master will set the state of all services on that slave into an UNKNOWN state. This filtering means that you will not get lots of notifications for a single issue when a slave has failed.

Note: Notifications that are sent from a slave are logged on the slave, but are not logged on the Opsview master.


This is the script to execute. It is assumed that this script is stored in /usr/local/nagios/libexec/notifications. Add any command arguments as required

Contact Variables

This is a comma separated list of variables that the notification method requires for each contact.

Note: The variables specified will be saved as custom contact variables of the format _{name}. However, EMAIL and PAGER are treated differently and will be saved as email and pager in the Nagios® Core configuration. PAGER is the variable used to hold a mobile phone number

Additional fields

There maybe additional fields based on the notification method:

AQL Username

AQL provide a simple way of transmitting SMS alerts from Opsview. This service works from most countries, all you need is an AQL account.

Sign up for prepaid credits at aql.com with the code 'opsera-1234' to receive discounted rates and 50 free credits.

This is the username for the AQL system. Click on Check Credit to see how many credits you still have from AQL

AQL Password

This is your AQL password.

AQL Proxy Server

AQL's solution requires that the Opsview server has connectivity to AQL over HTTP/80. AQL's messaging servers are:

  • gw1.sms2email.com
  • gw11.sms2email.com
  • gw2.sms2email.com
  • gw22.sms2email.com

These servers are used in a round robin fashion, so your firewall must allow connection to each one. If you use a web proxy server, enter the proxy information in the format:


Customising the Email Template

The email template is written in Template Toolkit and exists in /usr/local/nagios/libexec/notifications/com.opsview.notificationmethods.email.tt.

You can customise this file, but be aware that it will be overwritten as part of any future upgrades.

The patch below can be used to add a URL line to the email:

--- com.opsview.notificationmethods.email.tt.original	2010-09-16 16:05:14.000000000 +0100
+++ com.opsview.notificationmethods.email.tt	2010-09-16 16:06:25.000000000 +0100
@@ -25,6 +25,7 @@
 Date & Time: [% nagios.longdatetime %]
+URL: http://opsview.example.com/status/service?host=[% nagios.hostname %]
 Additional Information: 

A complete list of Nagios Core macros is available at: http://nagios.sourceforge.net/docs/3_0/macrolist.html

Adding a New Notification Script

You may want to use an existing Nagios Core notification script in Opsview. To add this in:

  • Check the notification script for any dependencies. This may require additional software to be installed on the Opsview master (and slaves)
  • Test the notification script. Opsview provides a way of simulating the environment variables that Nagios Core will set at notification time. If you intend to run this notification on slaves, you should test on those servers too:
su - nagios
/usr/local/nagios/utils/test_notifications hostproblem /path/to/notificationscript {other parameters}
  • Put your script into /usr/local/nagios/plugins/notifications on the Opsview master server, as the nagios user
  • If appropriate, run send2slaves -p to distribute to all slaves
  • Create a new Notification Method (Advanced ⇒ Notification Methods). Set appropriate configuration (see above)
  • Each contact will then have to select this notification method to one of their notification profiles
  • Reload Opsview to make the changes live
  • Cause a failure to test that the notification is sent

Writing Your Own Notification Script

Your notification script should be written to expect any input regarding the notification alert from Nagios Core via environment variables - see the Macro Availability Chart at http://nagios.sourceforge.net/docs/3_0/macros.html.

To distinguish between a service alert and a host alert, do something like (in perl):

  # This is a service alert
} else {
  # This is a host alert

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

You can then add this notification script to Opsview.