Opsview Knowledge Center

Notification Methods (Out of the Box)

Overview of Notification Methods.

Overview

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

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.

Default Notification Methods within Opsview Monitor

Default Notification Methods within Opsview Monitor

Notification Method 'Run On' option

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:

  • Orchestrator
  • Collector

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

Notes:

  • The advantage of running notifications from a Collector is that it is autonomous from the Orchestrator.
  • If you select Collector and the host that wants to send a notification is monitored by the Orchestrator server, then the notification will be sent from the Orchestrator server.
  • If a service is monitored by a Collector but the notification method is set to the Orchestrator, then the details of the notifications will be transferred to Orchestrator to be notified on.
  • There may be firewall restrictions to running a notification from a Collector.

Sent Notifications are visible in the Notifications View.

Email

This sends an email to the email address specified.

The email Notification Method requires minimal configuration:

  • Name: A name for the Notification Method
  • Enable: Tick that box to make the Email Notification Method available to use when creating Notification Profiles. Submitting a change to this checkbox will require to Apply Changes from the Configuration menu.
  • Run on: to set the system to send alerts either via the Orchestrator or the Collector servers (this can be useful if you have different configurations for postfix, sendmail, etc on your Collector servers than your Orchestrator).
  • Command: This is the script to execute. It is assumed that this script is stored in /opt/opsview/monitoringscripts/notifications. Add any command arguments as required if modifying the Notification Method .
  • User variables: 'EMAIL' is the name of a Variable that will be passed to the notify_by_email script and its value is the destination E-mail address for the Notification that will be defined in the User profile setup on the Configuration > Users and Roles > Users page.

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:

  • Postfix
  • Sendmail
  • Zimbra
  • .. more.

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 template is written in Template Toolkit and exists in /opt/opsview/monitoringscripts/notifications/com.opsview.notificationmethods.email.tt.

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

RSS

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.

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

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

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:

Correct Opsview.com Username and password

Correct Opsview.com Username and password

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

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

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

Correct Opsview.com Username and password

Correct Opsview.com Username and password

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

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.

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

SMS Notification Module

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

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

For information installing and configuring the SMS module, see Section SMS Module . WARNING: Not available by default on Opsview Monitor 6.0 AU. If you need it, please contact the Customer Success Team.

VictorOps

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.

  • First, in Opsview Monitor, activate the method by setting it to 'Enable', click 'Submit Changes' and go to Configuration > Apply Changes to make this change available to the Users screen.
  • Then go to http://www.victorops.com and sign up, if you do not already have an account.
  • Once logged in, navigate to 'Integrations' and create a new REST Endpoint.
  • Next, navigate to 'Settings > Schedules' and add a new Team, in order to get a Routing key for your Users:
  • Once the team is added scroll down until you see the team name and its schedule and click on 'Setup Routing':
  • Once you have clicked on 'Setup Routing', scroll down to the bottom of the page where you can view and add routing keys:

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

  • First, add the API Key (more specifically the part after '/alert/') to the Notification Method, as shown below:
  • Next, go to the User profile via Configuration > Users and Roles to add the 'VictorOps Routing Key'

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

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

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

Please 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

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.

  • First, in Opsview Monitor, activate the method by setting it to 'Enable', click 'Submit Changes' and go to Configuration > Apply Changes to make this change available to the Users screen.
  • Then go to http://www.pagerduty.com and sign up, if you do not already have an account.
  • Either as part of the sign up, or once already logged in, add a new 'Opsview' service:

Sign up ' 'Connect your first service: Opsview'

Logged in ' 'Configuration > Services'

  • Once the service is added, the 'API Key' will be visible as per the above and below screens:

You can now configure Opsview Monitor:

  • Add the API key on a user per user basis in the User profile via Configuration > Users and Roles, 'Notifications' tab:

Notifications should start arriving in PagerDuty:

You should start receiving emails in your inbox:

Please 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

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.

  • First, in Opsview Monitor, activate the method by setting it to 'Enable', click 'Submit Changes' and go to Configuration > Apply Changes to make this change available to the Users screen.
  • Then go to http://www.twilio.com and sign up, if you do not already have an account.
  • As part of the sign up, you will need to 'Get your Twilio number'. This is the phone number that voice calls and SMS are sent FROM, i.e. the caller.

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

  • Now that you have the three parts of information; the Account SID, the Auth Token and the Twilio Number, you can configure the Notification Method:
  • Add the telephone number on a user per user basis in the User profile via Configuration > Users and Roles, 'Notifications' tab, in the 'Mobile' field.
    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

Individual log, showing SMS message to the given phone number

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

Please 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

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.

  • First, in Opsview Monitor, activate the method by setting it to 'Enable', click 'Submit Changes' and go to Configuration > Apply Changes to make this change available to the Users screen.
  • Go to http://www.slack.com and sign up, if you do not already have an account. it will take you through the basic setup process of creating teams and rooms.
  • Once the setup is finished, log in and click on Integrations on the left-hand side. Then click on 'Make your own' which will take you down to the bottom of the screen.
  • After clicking 'Or, make your own!' click on the 'View button next to 'Incoming WebHooks':
  • Within the 'Incoming WebHooks' window, select the channel you wish to send Opsview Monitor Notifications into. In our example, we are going to send Notifications into the #support slack channel:
  • Once you have selected a channel, simply click on the 'Add Incoming WebHooks Integration' and your new WebHook is created:
  • Now that we have our WebHook, we can configure the Slack Notification Method :

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 Section 'Notification Profiles'.

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

Atlassian HipChat

This sends alerts into a HipChat room, for example, the support chat room.

HipChat is a 'chat room', that allows teams of Users to collaborate over the internet. The value-add over a chatroom is that HipChat 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 HipChat and follow the steps below to activate it on the Opsview system.

  • First, in Opsview Monitor, activate the method by setting it to 'Enable', click 'Submit Changes' and go to Configuration > Apply Changes to make this change available to the Users screen.
  • Go to http://www.hipchat.com and sign up, if you do not already have an account.
  • Once logged in, create a HipChat room via the 'Web App':
  • Give the room a name:
  • Once the room has been created, click on the 'HipChat logo' in the top left ' this will load the HipChat configuration section.
  • Click on 'Rooms' and you will be presented with a list of all the HipChat rooms:
  • Click on the newly created 'opsview-alerts' room, and make a note of the value in the 'API ID' field:
  • Click on the 'Tokens' menu item on the left-hand side:

This will load a window with a box:

  • Enter a label, i.e. 'Opsview Monitor', set the scopes to 'Send Notification' and click create. This will create a new token:
  • Now that you have the room notification token and the room's 'API ID', you can configure the HipChat Notification Method:

Note: The 'Authentication Token' is where you should enter the 'Room Notification Token'.

A Notification Profile that uses the 'HipChat' Notification Method must be configured. This is covered in Notification Profiles.

Notifications should start arriving in the opsview-alerts HipChat room:

ServiceNow

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

  • First, in Opsview Monitor, navigate to the Notification Method list. This can be found in Notifications > Notification Methods.

  • Click the contextual menu icon next to ServiceNow and select Edit.

  • The command in the Command box contains references to the variables surrounded by percentage mark (%) symbols. These variables allow you to configure the method with the Username, Password and Instance URL of the ServiceNow instance. The "out of the box" ServiceNow method uses the SERVICENOW_SETTINGS variable, but you can use any existing or newly created variable.

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.

  • Four flags exist that allow you to configure the behaviour of the ServiceNow scripts. To enable or disable these settings, simply append or remove the flags from the command.
Flag (short) Flag (long) Behavior
-a --auto_close Whether to close ServiceNow Incidents when the Incident is resolved. (Defaults to marking the Incident as Resolved)
-dp --decreasing_priority Without this setting on, all values set by State (such as Impact and Short Description) will use the worst State the Notification has hit. With it on, all state changes are reflected in the all fields.
-k --acknowledge Whether to Acknowledge Notifications successfully sent inside Opsview. Acknowledging a Notification in Opsview will stop any further state changes for the Incident being raised as Notifications until the resolution.
  • To create or edit a variable, go to Configuration > Variables. Editing SERVICENOW_SETTINGS will only affect the pre-defined ServiceNow notification method. To create a new variable please read Adding a Variable. The variable should follow this structure with Password optionally encrypted to increase security:
# Argument Label Value Command Flag (used in Notification Method Command)
1 Username Username of the User through which Incidents are created. -u or --username
2 Password Password of the User through which Incidents are created. -p or --password
3 Instance URL URL of the ServiceNow instance. -i or --instance-url
4 Config YAML Name Filename of the custom configuration file in /opt/opsview/monitoringscripts/etc/notifications (Covered later in this documentation and entirely optional). -f or --filename
  • Username and Password should be populated with the credentials of the user through which Incidents will be raised. We recommend creating a new account for this purpose so automatically created Incidents can be tracked by user. The rest_api_explorer and incident_manager roles and the roles they inherit are required for usage of this notification method.
  • Instance URL should be filled in with the base URL of the ServiceNow instance with no additional path afterwards. For example, https://demo.service-now.com not https://demo.service-now.com/incident_list.do.
  • Config YML Name is used to pass in a custom mapping file to the notification method. Further information on this can be found later in this page. The filename passed in here should be just the name of the configuration file located in /opt/opsview/monitoringscripts/etc/notifications, not the full path. For example, custom_servicenow.yaml instead of /opt/opsview/monitoringscripts/etc/notifications/custom_servicenow.yaml.

Example for SERVICENOW_SETTINGS Variable configuration

  • Submit changes then navigate to the User profile via Configuration > Users and Roles to add the notification method to the preferred Notification Profiles.
  • Reload and the ServiceNow notification method will now be set up.

Advanced Custom Mapping

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.

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

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

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.

Notification Methods (Out of the Box)


Overview of Notification Methods.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.