Welcome to docs.opsview.com

Notification Methods

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

Opsview ships with multiple notification methods, including:

  • Email - where you can send emails
  • RSS - for an RSS feed of notifications. More information here
  • iOS Push Notifications - sent to the Opsview Mobile app on iOS devices
  • Android Push Notifications - sent to the Opsview Mobile app for Android (due May 2014)

You can activate as many notification methods as you like.

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).


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 are using Service Desk Connector, this must be set to Master.

Note: 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.

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}. These variables can then be accessed in your notification script by the environment variable NAGIOS__CONTACT{name} (note the double underscore).

Note: 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. The variables are accessed via NAGIOS_CONTACTEMAIL and NAGIOS_CONTACTPAGER respectively.

AQL SMS Notifications

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:


Opsview Mobile for iOS Push Notifications

Use the 'Push Notifications For IOS Mobile' notification method to send push notifications to your iOS device.

More information at our Opsview Mobile page.

Configuration variables

IOSPush Username

The Opsview systems username, the same one used to log into our main web site.

IOSPush Password

The Opsview systems password, the same one used to log into our main web site.

IOS Proxy

If your server needs to route through a proxy, put its full address here, eg. http://example.com:8080

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

From Opsview 3.15.0, you can also reference some Opsview configuration variables. Currently the following are supported:

Code Description Example output
hostgroup=nagios.hostgroupname; matpath=config.hostgroups.$hostgroup.matpath.replace(”,”, ” > ”); matpath Returns the hierarchy that the host belongs to Opsview > Europe > UK > Monitoring Systems

From Opsview 3.15.0, you can change the default email template used. Set the command as notify_by_email -e email-template-name and Opsview will look for an email template in /usr/local/nagios/libexec/notifications/email-template-name. You can test your email template by running:

/usr/local/nagios/utils/test_notifications hostproblem /usr/local/nagios/libexec/notifications/notify_by_email -t -e email-template-name

This will output the contents of the email.

If you have changed the email template, you will need to redistribute the files to the other slaves. Run: send2slaves -p to send the contents to /usr/local/nagios/libexec to all slaves.


PagerDuty is now available out of the box with opsview. The user needs to setup an account on pager duty and follow the steps below to activate it on the opsview system.

  • Activate the method by setting it active from Settings→notification methods.
  • Go to http://www.pagerduty.com and sign up. Please make sure you provide them a valid email address as this where they will try to forward your notifications.
  • Follow pagerduty guide to setup a pagerduty service for opsview.
  • Once you have the key create a contact in opsview which will use pager duty as the notification method.
  • Provide the Service key in the notification tab of the contact.
  • Click on “Submit and edit notification profile”.
  • When loaded make sure the pagerduty is checked in the notify by options.
  • Submit and reload changes, once the reload finishes Pager Duty should be ready to receive messages.

Note: PagerDuty only works with Nagios notifications, BSM notifications are not currently supported.

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.

Nagios Core Variables

The environment variables available for notification methods are:


For example, in perl, reference the environment variables with:


In bash, reference the environment variables with:


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):

  # 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.


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.


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:

  • hostgroupX_servicegroupY
  • kZ_NAME

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})

BSM Variables

The following variables are available for notifications created from BSM:

  • OPSVIEW_OBJECTTYPE - one of BSMComponent or BSMService
  • OPSVIEW_NAME - name of BSM object
  • OPSVIEW_ID - id of BSM object
  • OPSVIEW_NOTES - a text extract of the notes for BSM object
  • OPSVIEW_TIMET - epoch seconds of the time of the notification
  • OPSVIEW_SHORTDATETIME - an iso8601 representation of OPSVIEW_TIMET in the format of YYYYY-MM-DDTHH:MM:SS
  • OPSVIEW_AVAILABILITY - percentage of the availability of the BSM object
  • OPSVIEW_AVAILABILITY_THRESHOLD - the threshold to alert about this object from the notification profile
  • OPSVIEW_LASTSTATE - previous state of the BSM object. See OPSVIEW_STATE
  • OPSVIEW_NOTIFICATIONNUMBER - current notification number
  • OPSVIEW_CONTACTNAME - name of contact for this notification
  • OPSVIEW_DETAIL - information about each related object to the BSM object. If access is not allowed, then will show an error message
  • OPSVIEW_OUTPUT - a short description of the BSM state
  • OPSVIEW_CONTACT_* - all contact variables for this user