How to configure notifications using NoMa

WAS THIS PAGE HELPFUL? Leave Feedback

Overview

Essentially, notification rules define the who, what, where, when, why, and how of alert notifications. Rules contain various directives including contacts and contact groups defining who is to receive notifications, what monitored hosts and services should be included or excluded in the notifying, where and when notifications should be sent, and which event states to notify upon. Notification rules can be enabled (active) and disabled, and rules can be set to escalate notifications after a specified number of notifications is reached. This page steps through how to configure a notification rule, and how to set up the contact association necessary for every host or service you desire to be controlled via NoMa.

The expandable image below illustrates a notification rule and points out the tabs where the components are defined and where they are incorporated into a rule.

Figure: Notification rule

Steps

Creating a notification rule

Before continuing below, you should configure contacts and contact groups as reviewed in Notifications and Downtime How To's. Then, follow the steps below to create a notification rule.

1. Go to Configuration > NoMa.
2. Select the Notifications tab.
3. Click the Create button on the right side of the screen, (select the pencil icon to edit an existing rule).
4. Enter the notification directives, we start with section for Notification Information;
   • Enter a Name which identifies the notification and is displayed on the front page.
   • Enter a Description, this is optional and simply describes the notification rule.
   • Next, check the Activated box to enable the notification rule.
   • The Owner directive identifies the owner of a rule and allows the user to edit his own rules, administrators can edit rules of every user. You can leave this at the default Nagios Administrator.
5. Next, in the Hosts and Services section, you will need to indicate which hosts, host groups, services, service groups and recipients are to be included or excluded in the notification rule.
   • The default " * " wildcard character indicates "all" possibilities, (e.g., all hosts). Any include fields that are empty are assigned an implicit " * " and will automatically match all possibilities.
   • In specifying comma-separated lists of hosts, hostgroups, services, servicegroups, or recipients for inclusion or exclusion filtering, '*' can be used as a multi-character wildcard and '?' can be used as a single-character wildcard, within any particular item in such a list. For Hosts and Services fields, typing a host name and pressing Tab will display a list of valid hosts and services.
   • An applied include constraint will only allow the notification rule to pass if the host or service belongs to at least one of the listed hostgroups or servicegroups. Conversely, an applied exclude constraint will only allow the notification rule to pass if the host or service does not belong to any of the listed hostgroups or servicegroups. See How to use Includes and Excludes filters in NoMa.
6. In the Contacts and methods to notify section you will need to select who will receive and how the notification will be received.
   • Select the Contact(s) and or Group(s) to be notified and the Method to be used to send the notification. An element in each of the Contacts, Groups, and Methods is only associated with the present notification rule if its background is grayed indicating it has been selected. To select a single element click on the element, to select more than one element use the Control, Command, or Shift keys while making a selection.
7. Next, select a Timezone to be used for the notification, and a Timeframe indicating the hours allowed for notifications to be sent.
8. Under the Which events to notify section, check (or uncheck) the filter options for the recovery, problem, state transitions, and other states of change for which to send notifications.
9. In the Numbers and more section, set the notify after number to indicate when notifications should start being sent, (e.g., 1 sends a first notification, 2-6 sends sends second through sixth notifications).
   • For Rollover if the last rule is reached directive, if checked NoMa will start notifications again from number 1 after the last notification (or escalation) has been reached.
   • The directive Let notifier handle escalations, if checked, enables NoMa to simulate the reception of notifications from Nagios and is useful for one-off alerts.
10. Select Create/Save.
11. And lastly, if you wish to continue notifications after the specified notify after directive you can add escalations. The escalations option is only displayed for previously defined notification rules.
    • Go to Configuration > NoMa > Notifications and select the pencil icon corresponding to the rule to update.
    • Then, select add Escalation toward the bottom of the screen and select the Contacts and or Groups to be notified and the Methods of communication.
    • As in the first notification, the Notify after number indicates when this notification should be escalated. An element in each of the Contacts, Groups, and Methods lists is only associated with the present escalation if its background is grayed which indicates it has been selected. To select a single element click on the element, to select more than one element use the Control, Command, or Shift keys while making a selection.
    • Click Save to save the escalation. Add additional escalationa or click Save again to save the notification rule.

      Deleting Contacts Groups associated with Escalations If you need to delete a contact group and it is associated with an escalation, you need to first delete the escalation, then delete the contact group. If you deleted a contact group that is associated with an escalation, this will cause a crash of the NoMa daemon and an error in the Debug Log.

Setting host and service notification commands

A script is provided for inclusion with Nagios as the notification command (host-notify-by-noma, service-notify-by-noma) that will be triggered for every host or service you desire to be controlled via NoMa.

If you are using a version of GroundWork Monitor prior to 7.2.0 please see About Notifications and Downtime for reference regarding updated host and service NoMa commands.

You will need to associate the NoMa commands with a contact, that contact with a contact group, and that contact group with every object that will be using NoMa to alert, along with the appropriate notify conditions and time periods. On the occasion of a state change, this notification transmits the specifics to the NoMa daemon by calling the script; the daemon uses the specifics passed in the script compared to the stored filters in the NoMa database and on a match sends out a NoMa message to the contacts named in that matching filter. NoMa sends the message using a different script, one of several available for choice in the filter setup.

In Nagios/Monarch you will need to add/edit the contact to be associated with the forwarding of the alerting. In the example below we use the nagiosadmin contact which has the assigned nagiosadmin contact group, and notify-by-noma commands. This will associate the alert via NoMa script as a notification command for hosts and for services with nagiosadmin contact. You will also need to make sure that all hosts for NoMa alserts are setup with this contact group, (e.g., nagiosadmin). You may want to create a new contact and contact group.

1. Go to Configuration > Contacts > Contacts > Modify, and select the contact to modify, (e.g., nagiosadmin).
2. Set the Host notification commands directive to host-notify-by-noma and the Service notification commands directive to service-notify-by-noma, (see image below).
3. Scroll down and set the contact group, (e.g., nagiosadmin), you may need to uncheck the inherit box to do so.
4. Click Save.
   
   Figure: Set notify-by-noma commands
   

Enabling and receiving notifications

Once notifications are enabled they can be received based on the methods defined and can be viewed in the NoMa application Logs tab.

1. In Nagios, the Enable notification directive on the Nagios main configuration page controls the enabling and disabling of system wide notifications. Go to Configuration > Control, expand Nagios main configuration, select Notification.
2. To enable check the box for Enable notifications, then click Save and Next >> 3 times, and Save and Done.
3. From the left side navigation select Commit and follow the process to commit the configuration change.
   
   Figure: Enable notifications
   
4. In NoMa, notification definitions can be turned on and off. To activate a notification definition, go to Configuration > NoMa > Notifications.
5. Toggle the check mark icon to be green (activate) for the corresponding notification rule.
   
   Figure: Activate a notification rule
   
   
   
6. Notifications will then be sent based on the directives set in the notification rule. The notification example email below shows the host d-exchange-2010.sales-demo.local in a CRITICAL state. The Link: is active and (if logged in) will go directly into the Status application for this device where you can acknowledge and or apply actions. 
   
   Figure: Example NoMa email notification

   ***** NoMa *****
   ID: 1
   Notification Type: PROBLEM
   Host: d-exchange-2010.sales-demo.local
   Host Alias: sales-demo
   State: DOWN
   Address: ###.##.###.##
   Link: http://docs.groundwork.groundworkopensource.com/portal-statusviewer/urlmap?host=d-exchange-2010.sales-demo.local
   Info: CRITICAL - ###.##.###.##: Host unreachable @ ###.##.###.##. rta nan, lost 100%
   Date/Time: Tue Dec 12 11:44:56 2017

7. The Logs tab displays NoMa notifications in a list which is accessible during runtime and displays alerts with status information in the order they are generated.
   • The boxes at the top of the list enable filtering by content for any of the columns, for instance you can enter "Service" for the Check type or a recipient's name under Recipient to filter by a specific notification recipient. 
   • The example output here is based on our notification rule above where the first 1-11 notifications go out to nagiosadmin, 12-19 are escalated to beckles, the 20th escalated to msnowden, and the 21st is a rollover back to the first notification nagiosadmin and continues in this same patter until the the notification is acknowleged or there is another state change.
     
     Figure: NoMa notification log
     

Log Files

• nagios.log

  cd /usr/local/groundwork/nagios/var

  cat nagios.log

• sendEmail.log

  cd /usr/local/groundwork/core/services/notification-noma

  cat sendEmail.log

• noma_debug.log

  cd /usr/local/groundwork/noma/var

  cat noma_debug.log

• noma_notify.log

  cd /usr/local/groundwork/noma/var

  cat noma_notify.log