How to configure notifications using NoMa

WAS THIS PAGE HELPFUL? {html}<a href="mailto:training@gwos.com?subject=How to configure notifications using NoMa">Leave Feedback</a>{html}\\
\\

{toc:minLevel=5|maxLevel=6|printable=false}

h5. 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
\\ !bookshelf_01_how_to_configure_notifications_using_noma.png|thumbnail!

h5. Steps

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

# Go to *Configuration* > *NoMa*.
# Select the *Notifications* tab.
# Click the *Create* button on the right side of the screen, (select the pencil icon to edit an existing rule).
# 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_.
# 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].
# 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.
# Next, select a *Timezone* to be used for the notification, and a *Timeframe* indicating the hours allowed for notifications to be sent.
# 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.
# 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.
# Select *Create*/*Save*.
# 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.

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.
{note}If you are using a version of GroundWork Monitor prior to 7.2.0 please see [About Notifications and Downtime|About Notifications and Downtime#nomacommands] for reference regarding updated host and service NoMa commands.{note}
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.
# Go to *Configuration* > *Contacts* > *Contacts* > *Modify*, and select the contact to modify, (e.g., nagiosadmin).
# 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).
# Scroll down and set the *contact group*, (e.g., _nagiosadmin_), you may need to uncheck the inherit box to do so.
# Click *Save*.
\\
\\
Figure: Set notify-by-noma commands
\\ !bookshelf_02_how_to_configure_notifications_using_noma.png|thumbnail!

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

# 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*.
# To enable check the box for *Enable notifications*, then click *Save and Next >>* 3 times, and *Save and Done*.
# From the left side navigation select *Commit* and follow the process to commit the configuration change.
\\
\\
Figure: Enable notifications
\\ !bookshelf_03_how_to_configure_notifications_using_noma.png|thumbnail!
# In *NoMa*, notification definitions can be turned on and off. To activate a notification definition, go to *Configuration* > *NoMa* > *Notifications*.
# Toggle the check mark icon to be *green* (activate) for the corresponding notification rule.
\\
\\
Figure: Activate a notification rule
\\ !bookshelf_04_how_to_configure_notifications_using_noma.png|thumbnail!\\
\\
# 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*&nbsp;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.&nbsp;
\\
\\
Figure: Example NoMa email notification
{noformat}***** 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{noformat}
# 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.&nbsp;
#* 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
\\ !bookshelf_05_how_to_configure_notifications_using_noma.png!

h5. Log Files

* *nagios.log*
{noformat}cd /usr/local/groundwork/nagios/var{noformat}
{noformat}cat nagios.log{noformat}

* *sendEmail.log*
{noformat}cd /usr/local/groundwork/core/services/notification-noma{noformat}
{noformat}cat sendEmail.log{noformat}

* *noma_debug.log*
{noformat}cd /usr/local/groundwork/noma/var{noformat}
{noformat}cat noma_debug.log{noformat}

* *noma_notify.log*
{noformat}cd /usr/local/groundwork/noma/var{noformat}
{noformat}cat noma_notify.log{noformat}