Notification Methods

Notification Methods are the medium through which you are notified regarding problems detected by the Opsview Monitor software.

By default, Opsview Monitor ships with the following Notification Methods and their setup is accessible on the Configuration > Notification Methods page.

Configuring Notification Methods Copied

Some of these notifications require modification, i.e. the Push methods require a Username and password, Slack requires a Webhook URL and so forth. The modification of the Notification Methods is done via Configuration > Notification Methods.

Notification Methods

Notification Method ‘Run On’ option Copied

On a system with clusters configured, each notification method has a ‘Run On’ option. This option allows you to specify whether the notification method is run on:

Some methods, such as ‘Service Desk Connector’ must be set to Orchestrator.

Take note of the following:

Sent Notifications are visible in the Notifications View.

Email Copied

This sends an email to the email address specified.

Creating email

Note

If the mail relay server does not advertise UTF-8 support, it may block emails sent by Opsview that contain non-ASCII UTF-8 characters.

The email Notification Method requires minimal configuration:

The 'notify_by_email' command will use the configuration defined on the local server; be it the Orchestrator or the Collector server. The local email server configuration can be one of many including:

Note

The default mail script 'notify_by_email' uses mail binary path '/usr/bin/Mail'. Please correct the script to point to a valid mail binary if required. You can find the script here: /opt/opsview/monitoringscripts/notifications/notify_by_email.

Simply ensure that the local mail server is configured correctly and can successfully deliver emails to email addresses. Generally configuring the local email server as a simple relay Host is sufficient, i.e. setting 'relayHost = mail.company.com' for example (For postfix: /etc/postfix/main.cf )

To change the ‘sender address’ for email notifications, simply modify /etc/mailname for the domain section (i.e. right of ‘@’). To modify the User/account section, i.e. ‘opsview@’, follow the specific guides for your email server of choice. In postfix, you can adjust this using the ‘sender_canonical_maps’ configuration parameter. For a guide see the Ubuntu Forums post here: http://ubuntuforums.org/showthread.php?t=38429.

The email templates are written in Template Toolkit and exist at /opt/opsview/monitoringscripts/notifications/com.opsview.notificationmethods.email.tt and /opt/opsview/monitoringscripts/notifications/com.opsview.notificationmethods.email.opsview.tt.

Warning

Do not edit the /opt/opsview/monitoringscripts/notifications/com.opsview.notificationmethods.email.tt and com.opsview.notificationmethods.email.opsview.tt files, as any changes you make will be overwritten and lost. Instead, follow the instructions at Custom Email Templates.

Custom Email Templates Copied

To create and use a custom email template when sending notifications, you can do following workaround:

  1. Create your custom template file in a temporary location, for example /tmp/my.email.template.tt

  2. Copy the existing notify_by_email notification script to a new temporary file with a different name, for example /tmp/notify_by_email2.

  3. Open the new file and edit it manually to replace the strings /opt/opsview/monitoringscripts/notifications/com.opsview.notificationmethods.email.tt and /opt/opsview/monitoringscripts/notifications/com.opsview.notificationmethods.email.opsview.tt with /opt/opsview/monitoringscripts/etc/notifications/my.email.template.tt. Take note of the etc in the path.

  4. Import your new notification script using this command:

    sudo -u opsview /opt/opsview/orchestrator/bin/orchestratorimportscripts notifications /tmp/notify_by_email2`.
    
  5. Import your custom template file using this command. Take note of the etc in the argument:

    sudo -u opsview /opt/opsview/orchestrator/bin/orchestratorimportscripts etc-notifications /tmp/my.email.template.tt`
    
  6. Click Apply Changes in Opsview.

  7. Create a new Notification Method using the Opsview UI or API which uses your new notification script.

  8. Use the new Notification Method.

  9. Click Apply Changes again. This will make the notification method available and distributed to collectors.

RSS Copied

This publishes the problems as an RSS feed on a per User basis. Access to the RSS feed requires authentication so that only the correct Notifications are accessed. This uses basic authentication as RSS readers only support basis authentication.

Creating RSS

This method runs only on the Orchestrator server.

Notifications are written to an RSS file for each contact. The RSS feed is at http://opsview.example.com/abc. Where opsview.example.com is your Opsview web server address.

Access to the RSS feed requires authentication so that only the correct notification file is accessed. This uses basic authentication as most RSS readers only support basic authentication.

Push Notifications For iOS Mobile Copied

This sends push Notifications to the Apple Opsview Mobile App to the Username/Password specified.

Notifications for iOS mobile

To enable push Notifications:

  1. You must include your valid Opsview.com Username (not email address) and password in the app, and in the Opsview Monitor ‘Push Notifications for iOS Mobile’ settings fields, like the screen.
  2. Your iOS device must be able to do a one-time connect to your Opsview Monitor Orchestrator server in order to retrieve it’s UUID for registration of the device on push.opsview.com.
  3. Your iOS device must be able to connect to push.opsview.com via HTTPS.

To configure the ‘Push for iOS’ Notification Method, you only need to enter two items of information; the Opsview.com Username and password. After clicking ‘Test Connection’, you should see one of the two messages below:

Enable notifications

If the Opsview Monitor system does not have direct access to the internet, you can specify a Proxy in the text box labelled ‘Proxy:’ and re-test the connection. Once the connection succeeds, that is the configuration completed.

Push Notifications for Android Copied

This sends push Notifications to the Android Opsview Mobile App to the Username/Password specified.

Notifications for Android

To enable Push Notifications:

  1. You must set a valid Opsview.com Username and password in the app in order for it to be able to register itself with Opsview Monitor’s push servers. You also need a valid Opsview.com username and password in the Opsview Monitor ‘Push Notifications for Android Mobile’ settings fields (pictured above) so that the Opsview Monitor server can send outgoing push notifications. These two Opsview.com accounts do not need to be the same and you can use a generic account for your Opsview Monitor notification method.
  2. Your Android device must be able to do a one-time connect to your Opsview Orchestrator server in order to retrieve it’s UUID for registration of the device on push.opsview.com.
  3. Your Android device must be able to connect to push.opsview.com via HTTPS.

To configure the ‘Push for Android’ Notification Method, you need to check the ‘Enable" checkbox. Submitting a change to this checkbox will require running Apply Changes from the Configuration menu. Then enter the Opsview.com Username and password. After clicking ‘Test Connection’, you should see one of the two messages below:

Enable notifications

If the Opsview Monitor system does not have direct access to the internet, you can specify a Proxy in the text box labelled ‘Proxy:’ and re-test the connection. Once the connection succeeds, that is the configuration completed.

AQL Copied

This provide a simple way of transmitting SMS alerts from Opsview through this web-based SMS gateway. This service works from most countries; all you need is an AQL account.

Creating AQL

It requires a valid AQL Username/password with account credit. Opsview Monitor tells the AQL Gateway the message and the mobile phone / cell number via HTTPS, and AQL will then send an SMS/Text message to the number provided. Sign up for prepaid credits at aql.com with the code ‘opsera-1234’ to receive discounted rates and 50 free credits.

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

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 within the ‘Proxy:’ field, in the format: http://User:password@Host:port/.

SMS Notification Module Copied

This sends an SMS via the physical modem attached to the Opsview Orchestrator/Collector server which must be connected to a POTS network.

Creating SMS notifications

This Notification Method is used for sending SMS messages via directly attached GSM modems.

For information installing and configuring the SMS module.

Warning

SMS module is not available by default on Opsview Monitor. If you need it, please contact the Customer Success Team.

VictorOps Copied

This sends Notifications to VictorOps, a SaaS notification routing platform.

Within VictorOps, you can create rules to dispatch alerts via various methods such as SMS, Email, etc to individuals or groups of Users. Users need to setup an account on VictorOps and follow the steps below to activate it on the Opsview system.

Now that you have the API key (as seen above) and the routing key (as seen above), you can now configure Opsview Monitor.

Note

If you do not see this field, it is likely you have not checked the ‘Enable" field in the VictorOps Notification Method.

VictorOps Routing Key

Once the Notification Profile is configured, Notifications should start arriving in VictorOps:

Configuring Notification Profile

If you have configured your team schedules correctly, you should start receiving emails in your inbox:

Receiving emails

Note

This Guide was written August 2015. The VictorOps.com User interface may have changed since; therefore, please let us know if any screens are out of date.

PagerDuty Copied

This sends Notifications to PagerDuty, a SaaS notification routing platform.

Within PagerDuty, you can create rules to dispatch alerts via various methods such as SMS, Email, etc to individuals or groups of Users. Users need to setup an account on PagerDuty and follow the steps below to activate it on the Opsview system.

You can now configure Opsview Monitor:

Notifications should start arriving in PagerDuty:

Notifications in PagerDuty

You should start receiving emails in your inbox:

PagerDuty sample email alert

Note

This Guide was written August 2015. The PagerDuty.com User interface may have changed since, therefore please let us know if any screens are out of date.

Twilio Copied

This sends a Notification to Twilio, a SaaS notification routing platform.

Within Twilio, you can create rules to dispatch specific types of notifications, including voice calls. Users need to setup an account on Twilio and follow the steps below to enable it on the Opsview system.

You can see the three required information: the Account SID, The Auth token and the Twilio number.

Note

You must verify this telephone number from Twilio first.

In order to send notifications into Twilio, a Notification Profile that uses the ‘Twilio’ Notification Method must be configured. This is covered in Section Notification Profiles

Once the Notification Profile is configured, notifications should start arriving in Twilio, as shown below:

SMS and MMS Logs

SMS and MMS logs

Twilio Message Details

Individual log, showing SMS message to the given phone number

If you have configured your phone number, you should start receiving text messages.

Note

This Guide was written August 2015. The Twilio.com User interface may have changed since, therefore please let us know if any screens are out of date.

Slack Copied

This sends alerts into a Slack room, for example: #support.

Slack is a ‘chat room’, that allows teams of Users to collaborate over the internet. The value-add over a chatroom is that Slack allows ‘inbound integrations’ from various tools such as Opsview Monitor. This means that an ‘Operations team’ can have a chat room, where alerts from Opsview are sent - they can discuss and view Notifications in the same forum - as opposed to a standalone email. Users need to setup an account on Slack and follow the steps below to activate it on the Opsview system.

The ‘WebHook URL’ is visible in the screen above, and the ‘Channel’ was set during the creation of the WebHook; i.e. #support.

A Notification Profile that uses the ‘Slack’ Notification Method must be configured. This is covered in Notification Profiles.

Once the Notification Profile is configured, Notifications should start arriving in the #support Slack room:

Sample message in Slack

Multiple Slack methods Copied

The below details adding additional Slack Notification Methods. You will need to obtain the slack webhook associated with your desired channel as described in the above section. To recap you will need to create an app in Slack at https://app.slack.com/apps-manage/ with permissions to post into your required channels.

You will need to create a new VARIABLE too, which is covered after this section, but importantly, that new VARIABLE name will need to match what is set here or vice versa depending on the order you create them in.

Select “Add New” within Notification Methods and enter the below as the Command; this example uses SLACKNOC as the VARIABLE name.

notify_by_slack slacknoc -c %SLACKNOC% -u %SLACKNOC:1% 

The options used in the command are as follows:

If not already done, create the VARIABLE via the Configuration > Variables page as follows:

Creating variables

After performing an Apply Changes, you should now start to get notifications into your Slack channel (you can also check this via the Test tab on the Notification Method)

Microsoft Teams Copied

This sends alerts into a Teams channel. This is useful so you can collaborate on alerts and discussions in the same location.

Prerequisites Copied

Note

You will need to ensure a network connection is open from your Opsview orchestrator server to the Webhook URL’s host on port 443.

Then in Opsview Monitor:

ServiceNow Copied

The ServiceNow Notification Method allows notifications from Opsview to be opened as Incidents under an instance of ServiceNow - a SaaS IT Incident management system. Opsview Monitor comes with a predefined notification method for ServiceNow allowing for easy out of the box configuration. It is also possible to manually add more methods using the notification script to point at different ServiceNow instances if required. To configure either approach, follow these steps:

Basic Configuration Copied

Example for ServiceNow Command box:

notify_via_nagios notify_by_servicenow -u "%SERVICENOW_SETTINGS:1%" -p "%SERVICENOW_SETTINGS:2%" -i "%SERVICENOW_SETTINGS:3%" -f "%SERVICENOW_SETTINGS:4%" -dp -k -r

Note

To create multiple notification methods pointed at different Instances, simply create a new Notification Method that duplicates the example above but with a new VARIABLE name instead of SERVICENOW_SETTINGS.

Example for SERVICENOW_SETTINGS variable configuration:

ServiceNow settings

Advanced custom mapping Copied

In addition to the configuration found in SERVICENOW_SETTINGS, the contents of the requests created by this notification method can be further customized by creating a custom mapping file. The file servicenow.yaml.default is located in /opt/opsview/monitoringscripts/etc/notifications/ and is an example of such a mapping file used by the script to generate requests if no custom file is passed in.

To add custom mapping files, use the orchestratorimportscripts helper tool on the Opsview Orchestrator server, as the opsview user:

sudo -u opsview /opt/opsview/orchestrator/bin/orchestratorimportscripts etc-notifications /path/to/custom/file/source

This will add the file to the correct location with the correct permissions. When finished, click Apply Changes.

The default configuration file contains the setup for two mappings and four notification states. Any values set in a custom configuration file are loaded in over the defaults. Likewise, any values missing from a custom configuration fall back to the defaults. All of this means that to make a small change (for example, the short_description for Host notifications) would only need a custom file made with the lines below in.

servicenow:
  common_field_map: # Field Map
    host: # Incident Type
      comments: "{HOSTNAME}\n{COMMENTS}" # Values
      short_description: "{HOSTNAME}/{HOSTGROUPNAME} is {HOSTSTATE}"
    service_check:
      comments: "{COMMENTS}"
      short_description: "{SERVICEDESC} on Host {HOSTNAME}/{HOSTGROUPNAME} is {SERVICESTATE}"

Incident types Copied

A configuration YAML can define the contents of an Incident raised depending on the state of the Notification. The following field_map’s relate to states of Notifications and each can therefore be configured individually.

common_field_map

common_field_map is the base mapping section, being the fallback for the other 3 settings. In a similar way to how a custom yaml overwrites the default yaml, initial, update and recovery field_mappings overwrite values found in the common field map and the common fills the gaps in the others. Any values set here will be used for every type of notification unless explicitly set otherwise.

initial_field_map

initial_field_map contains the mappings for when an Incident is initially raised.

update_field_map

update_field_map contains the mappings for when an Incident is being updated.

recovery_field_map

recovery_field_map contains the mappings for when an Incident is being resolved.

Values Copied

The following fields are only the ones by the default mapping. With a custom configuration file, any values can be sent to ServiceNow, including custom fields defined in the Incident table as every field equates to one key in the request sent to ServiceNow to create the Incident.

comments

The comment to add when the Incident is updated on ServiceNow.

short_description

The short description of an Incident is used by ServiceNow as a title for the Incident.

incident_state

The state of the Incident in ServiceNow.

impact

The impact of the Incident in ServiceNow.

The following keys can be used in the configuration YAML to define custom fields and overwrite default ones.

Key Value
{HOSTGROUPNAME} Name of the Host Group the Notification originates from.
{HOSTADDRESS} Address of the Host the Notification originates from.
{HOSTSTATE} State of the Host the Notification originates from.
{HOSTSTATETYPE} State type (Hard or Soft) of the Host’s state.
{HOSTOUTPUT} Output of the last Host check.
{LASTHOSTUP} Timestamp the Host was last up.
{SERVICENOTES} Description of the Service Check the Notification originates from.
{SERVICEDESC} Name of the Service Check the Notification originates from.
{SERVICESTATE} State of the Service Check the Notification originates from (OK/WARNING/CRITICAL/UNKNOWN).
{SERVICEOUTPUT} Output of the Service Check the Notification originates from.
{SERVICESTATETYPE} State type (Hard or Soft) of the Service Check’s state.
{LASTSERVICEOK} Timestamp the Service Check was last OK.
{IMPACT} Impact of the Incident based on the notification state and the impact_map in the YAML.
{PRIORITY} Priority of the Incident based on the notification state and the priority_map in the YAML.
{COMMENTS} Comment string generated by the script for the notification.
{LASTCHECK} Timestamp of the last Service/Host check.
{LASTSTATE} Last recorded state of the Incident.

Using the above information, if you (for example) wished to set a correlation_id for each Notification based on some of the Keys above, you could add it to common_field_map like so.

servicenow:
  common_field_map:
    host:
      correlation_id: "{HOSTNAME};;{LASTHOSTUP}"
    service_check:
      correlation_id: ""{HOSTNAME};{SERVICEDESC};{LASTSERVICEOK}"

Now that the ServiceNow notification method(s) have been set up, notifications created from the Hosts and Service Checks assigned to Notification Profiles with the method selected will have corresponding Incidents created in ServiceNow. The first appearance of an issue will cause an Incident to be created with further state changes updating the Incident until the state returns to OK or UP where it will be marked as Resolved or Closed based on the value passed. Additional changes to the Incident will be logged as comments on the Incident’s page.

To learn more about what you can do with Incidents in ServiceNow after they’ve been created, look at ServiceNow - Incident Management.

Custom Methods Copied

Please see Custom Notification Methods for creating your own method.

["Opsview"] ["User Guide"]

Was this topic helpful?