Notification Configuration

Version 11 by Bren Eckles
on May 16, 2014 12:38.
<< Changes from 10 to 11
compared with
Current by Bren Eckles
on Oct 20, 2017 11:57.
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (61)

View Page History
...

This document describes how one configures and uses Notification Manager (NoMa) with GroundWork Monitor.
{toc:minLevel=4|maxLevel=5|printable=false}
{toc:minLevel=1|maxLevel=4|printable=false}

h4. 1.0 Managing Notifications with NoMa
h1. 1.0 Notification Rule Components

Be aware that active notifications that are being processed by NoMa may not take account of changes made after they are started. In this document we take a look at an alternative way to set up notifications and escalations using the Notification Manager (NoMa) application that is integrated into GroundWork Monitor. We'll use a 3 tier example using contacts, contact groups and escalations. We'll need to make some adjustments so that Nagios sends the notifications through NoMa.
In this section we focus on the components, including Contacts, Holidays, Contactgroups, Timeframes and Methods, which make up a notification rule used to send out alert notifications. The image below illustrates a notification rule and points out the tabs where the components are defined and where they are incorporated into the rule.

h5. 1.1 Launching NoMa
Throughout the various tabs; the _Create_&nbsp;button is used to produce a new definition, the _Pencil_&nbsp;icon to update an existing definition, the _Plus_&nbsp;icon to copy an existing definition, and the _X_ icon is used to delete a definition. {color:#333333}Defined components can then be applied within the&nbsp;{color}{color:#333333}{_}Notifications{_}{color}{color:#333333}&nbsp;tab.&nbsp;{color}This section describes each of the components directives.&nbsp;

| * Launch NoMa from GroundWork Monitor by selecting *Configuration* > *NoMa*. | Figure: Launching NoMa \\ !1.jpg|border=1! |
Figure: Notification rule
\\ !bookshelf_01_how_to_configure_notifications_using_noma.png|thumbnail!

h4. 2.0 Managing Contacts and Contact Groups
h4. 1.1 Contacts

h5. 2.1 Timeframes
Contacts are individual definitions indicating who should get notified and how and when they should get notified in the event of a problem on your network. Contacts are applied in the _Contactgroups_, _Holidays_ and _Notifications_ tabs.

Before we dive into adding contact and contact groups let's take a look ad Timeframes. Timeframes are lists of times during various days that are considered to be _valid_ times for notifications and service checks. They indicate when host and service notifications can be sent out to contacts and when notification escalations can be used. Timeframe information is defined in the Timeframes tab and applied within the Notifications tab.
| * Select the *Timeframes* option from within NoMa. | Figure: Notification Timeframes \\ !timeframes1.jpg|border=1! |
| * Let's take a look at a defined timeframe. Select the *Edit* icon (pencil) corresponding to the *workhours* timeframe name.
* Here you can see that for Monday through Friday from 8:00 AM until 4:00 PM are _valid_ times for notifications.
* Also note that all days are checked with *All* indicating that&nbsp; when using this timeframe the notification will start and include all notifications from the beginning.
* The *Validity Information* lets you set a date for which this timeframe definition is valid. | Figure: Example Timeframe\\
!timeframes2.jpg|border=1! |
|| Directive || Description ||
| Full Name | Full name of the person to receive the notification, displayed in various screens as the contact name. |
| Username | User name, displayed in the _Logs_ tab as a notification recipient. |
| Timezone | Sets the time zone of the contact. \\
NoMa makes use of the Perl DateTime::TimeZone to provide proper time zone support (including winter/summer time) and simplifies worldwide support for working hours , (e.g., _America/Los_Angeles_). |
| Timeframe | Sets the contacts availability to receive notifications, (e.g., _24x7_). \\ |
| Suppress multiple alerts | If _checked_, no more than one notification for the&nbsp;_same_&nbsp;alert condition&nbsp;will be sent out to this particular contact. \\
If _unchecked_, indicates the contact will receive more than one notification for the _same_ alert condition, if more than one alert is sent in for that condition. \\ |
| Contact addresses | Sets the contact's information for notifications: email, phone, mobile, [Growl|http://growl.info/] address. |
| Holiday | Indicates a period of time a contact should not receive notifications. Selecting this option opens the Holidays tab and returns to the Contacts tab. |

h5. 2.2 Adding contacts
h4. 1.2 Contactgroups

Upon launching NoMa the first screen displayed is *Notifications*. Adding of contacts is done via the *Contacts* link.
Contact groups are definitions of one or more contacts and can be used to send alert or recovery notifications to a group of contacts. Contact groups can be created for an area of expertise (e.g., _network-administrators_) or geographic location (e.g., _san_francisco-support_). When a host or service has a problem or recovers, _NoMa_, as configured, will find the appropriate contact groups to send notifications to and notify all contacts. These _Groups_ are applied in the _Notifications_ tab.

| * Select *Contacts* from the menu bar. | Figure: Accessing Contacts\\
!2.jpg|border=1! |
| Create the following contacts, selecting *Create* after each.
* For example: *Username*: pjefferson, *Full Name*: Pete Jefferson, *Password*: pjefferson, *Contact email*: (use one that you can test here), *Working hours*: 24x7, and *Timezone*: GMT | Figure: Creating Contacts\\
!3.jpg|border=1! |
|| Directive || Description ||
| Name (short) | Name of the contact group. \\ |
| Name (long) | Descriptive name. \\ |
| Timezone | Sets the time zone of the contact group. \\
NoMa makes use of the Perl DateTime::TimeZone to provide proper timezone support (including winter/summer time) and simplifies worldwide support for working hours , (e.g., _America/Los_Angeles_). \\ |
| Notification hours (Timeframe) | Sets the contact groups availability to receive notifications, (e.g., _24x7_). \\ |
| Do not send notifications (to members) \\ | If _checked_, contact group is a view-only group and notifications are not sent. The contact group is ignored while evaluating notification rules in response to incoming alerts. \\
If _unchecked_, notifications are sent to the contact group per notification rules. |
| Members | Sets the contacts to be included in the contact group, the individuals that will be notified. |

h5. 2.3 Creating contact groups
h4. 1.3 Holidays

Next, you can create contact groups which is a grouping of contact definitions and used in the configuration of notifications. Select *Contactgroups* from the main menu.
Holiday definitions Indicate a period of time a contact should not receive notifications. The Holiday option is only displayed for previously defined contacts. _Holidays_ are applied in the _Contacts_ tab.

| For example: \\
* *Name (short name)*: helpdesk-admins, *Name (long name)*: HelpDesk, *Timezone*: (select appropriate), *Notification Hours*: 24x7, *Members*: Pete Jefferson
* *Name (short name)*: customer-service-admins, *Name (long name)*: Customer Service, *Timezone*: (select appropriate), *Notification Hours*: 24x7, *Members*: Sally Johnson
* *Name (short name)*: emergency-services-admins, *Name (long name)*: Emergency Service, *Timezone*: (select appropriate), *Notification Hours*: 24x7, *Members*: Steve Jackson | Figure: Creating Contact Groups\\
!4.jpg|border=1! |
|| Directive || Description ||
| Name | Name for holiday. |
| Start | Start day and time. |
| End | End day and time. |
| Timeframe | Sets time frame in which holiday is effective. |
| Contact | Sets defined contact associated with the holiday adding holiday to Contact's definition. |

h4. 3.0 Managing Notifications
h4. 1.4 Timeframes

h5. 3.1 Understanding notification options
Schedule information including day of week, times and monthly occurrence. _Timeframes_ are applied in the _Contacts_, _Holidays_, _Contactgroups_ and _Notifications_ tabs.

Now that we have our contacts and contact groups created we can create notifications. Let's first take a look at the NoMa system default notification and understand the options. In summary, this *default* notification is active *24x7* in the time zone of *GMT*, and sends out alerts via *email* to the *Nagios Administrator* about all monitored *service groups* and *services*, *host groups* and *hosts* that have a status of *Warning*, *Unknown*, *Critical*, *Host Unreachable*, or *Host Down*. In addition if any of these devices have *started* or *stopped Flapping* or have had *Flapping disabled*, *Downtime started* or *ended*, or have had *Downtime cancelled*, have been *Acknowledged*, have had a *Custom* item associated, or have *recovered* with a *Service OK* and/or *Host Up* status.

| *Notification Option Descriptions* \\
* *Notification Information* \- The *Notification name* is used to identify your notification and is displayed within the Notifications front page. The *Description* field provides space for optional notification description.
* *Hosts and Services* \- These fields indicate which *recipients* and *devices* are to be included or excluded in the notification rule. The " * " wildcard can be used to select "all" recipients or devices and hosts and services should be comma-separated. Any include fields that are empty are assigned an implicit " * " and will automatically match all possibilities.
* *Contacts and Methods* \- The selected users for *Contacts* and/or the selected groups for *Groups* are those who will be notified. Notifications will be sent based on the filters you configure. *Methods* indicates the method(s) to be used to send the notification (e.g. email). The *Timeframe* and *Timezone* selections indicate the hours allowed for notification alerts within the specified time zone.
* *Which events to notify*: These filter options specifically define the recovery, problem, problem transitions and other states of change for which to send notifications. The *Notify after* entry sets the "start after this number of notification(s)" rule. Checking *Let notifier handle escalations* will cause NoMa to simulate the reception of notifications from Nagios and is useful for one-off alerts. Enabling *Rollover if the last rule is reached* causes NoMa to start again at number 1 when the last notification has been reached.
* *Add Escalation* \- Lets you define escalations for the notification. \\ | Figure: Notification Definition\\
!5.jpg|border=1!\\
Figure: Add Escalation \\ !esc.jpg|border=1! |
|| Directive || Description ||
| Name | Name of time frame. |
| Schedule Information | Sets time frame including day of week, from and to times with invert option (outside of _from_ and _to_ times), and choice of monthly occurance. |
| Validity Information | Valid dates and time of time frame. |

h5. 3.2 Creating notifications
h4. 1.5 Methods

Let's set up our own 3 tier notification and escalation rule. In summary we should end up with the *Entire Network* notification that is active *24x7* in the time zone of *GMT* (or your local time), and sends out alerts via *email* to the contact group *Helpdesk*, about all monitored devices in the entire network that have a status of *Warning*, *Critical*, or *Host Down*, indicates *Downtime started* or *ended*, or *cancelled*, and if a device has *recovered* with a *Service OK* and/or *Host Up* status. In addition, the notification should be escalated after 2 notifications to the host group *Customer Service*, and again after 3 notifications to *Emergency Services*.
Individual notifications are configured in Methods. The name of a method definition is associated with a command, contact and in some instances a sender. The system defaults for each method are listed in the table below. _Methods_ are applied in the _Notifications_ tab.

| * Select *Notifications* from the main menu and create the rule as described above and illustrated here. | Figure: Configuring Notifications\\
!6.jpg|border=1! |
| * Switching back to the *Notifications* page you can see the new notification listed.
* The *Actions* buttons represents active (*green check*) or non-active (*grey check*), *Edit* (pencil icon), *Copy* (green \+), and *Delete*. (red x). You can also view a summary of the filters that have been defined as part of the notification, in our case we do not have any specific setting for devices or recipients. | Figure: Notifications List\\
!7.jpg|border=1! |
|| Directive || Description ||
| Name | Name of method, e.g., E-Mail, Growl, SMS |
| Command, Contact Field, Sender (method defaults) | *E-Mail*: Emails are sent using the standard system mailer, you may need to configure your mail relay to accept mail from the system. \\
_Command_: sendemail, _Contact_: email, _Sender_: root@localhost, _Fallback method_: none, _Acknowledable_: No \\
See [How to enable sendEmail to work with TLS]. \\
\\
*Growl*: Growl notifications are sent using an included script, it requires the Perl module Net::Growl and by standard it uses UDP 9887 by default. After install, allow notifications from network, optional require password from LAN, server only requires Perl module Net::Growl as stated earlier. Client, depending on OS, requires an extra client: Mac:[http://growl.info|http://growl.info] Linux: [http://mattn.github.com/growl-for-linux/|http://mattn.github.com/growl-for-linux] Windows:[http://www.growlforwindows.com/gfw|http://www.growlforwindows.com/gfw]\\
_Command_: growl, _Contact_: growladdress, _Sender_: none, _Fallback method_: none, _Acknowledable_: No \\
\\
*SMS*: SMS alerts are sent via an attached SMS-capable modem using smstool3 or an iSMS/SMSFinder hardware device. \\
_Command_: sendsms_, Contact_: mobile, _Sender_: none, _Fallback method_: none, _Acknowledable_: No \\
\\
*Voice*: Voice alerts are generated with an Asterisk (or Starface) soft PBX. \\
_Command_: voicecall_, Contact_: phone, _Sender_: none, _Fallback method_: none, _Acknowledable_: Yes \\
\\
*Voice + E-Mail fallback*: Voice alert with email method fallback. \\
_Command_: voicecall_, Contact_: phone, _Sender_: none, _Fallback method_: E-Mail, _Acknowledable_: Yes \\
\\
*Voice + SMS fallback*: Voice alert with SMS method fallback. \\
_Command_: voicecall_, Contact_: phone,\_ _Sender{_}_: none,_ Fallback method_: SMS,\_ _Acknowledable_: Yes \\ |
| Fallback method | Method used if first method returns an error. This is currently only used by the voicecall plugin, to provide fallback to SMS or Email. |
| Acknowledgable | Any method that is configured as acknowledable will cause the escalation chain to end, typically only voice should use this method as E-Mail and SMS provide no guarantee that a message has been received and understood. |

h4. 4.0 Nagios/NoMa Setup and Activating NoMa Notifications
h1. 2.0 Configuring Notifications

h5. 4.1 Nagios script setup and contact associations
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.

A script is provided for inclusion with Nagios as the _notification command_ that will be triggered for every host or service you desire to be controlled via NoMa. You have to associate that command with a contact, that contact with a contact group, and the 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. Following is the definition of the host and service notify to NoMa commands, with a list of Nagios macros that are passed in to the NoMa daemon so it can compare to its filters the given event. You will need to reference these in the setup below.
h4. 2.1 Notification Rules

{code}define command{
command_name host-notify-by-noma
command_line /path_to_noma/alert_via_noma.pl -c h -s "$HOSTSTATE$" -H "$HOSTNAME$" -G "$HOSTGROUPNAMES$" -n "$NOTIFICATIONTYPE$" -i "$HOSTADDRESS$" -o "$HOSTOUTPUT$" -t "$TIMET$" -u "$HOSTNOTIFICATIONID$" -A "$NOTIFICATIONAUTHORALIAS$" -C "$NOTIFICATIONCOMMENT$" -R "$NOTIFICATIONRECIPIENTS$"
}
Follow the steps below to create a notification rule. You may want to configure notification components to be used in the notification rule before you start.

define command{
command_name service-notify-by-noma
command_line /path_to_noma/alert_via_noma.pl -c s -s "$SERVICESTATE$" -H "$HOSTNAME$" -G "$HOSTGROUPNAMES$" -E "$SERVICEGROUPNAMES$" -S "$SERVICEDESC$" -o "$SERVICEOUTPUT$" -n "$NOTIFICATIONTYPE$" -a "$HOSTALIAS$" -i "$HOSTADDRESS$" -t "$TIMET$" -u "$SERVICENOTIFICATIONID$" -A "$NOTIFICATIONAUTHORALIAS$" -C "$NOTIFICATIONCOMMENT$" -R "$NOTIFICATIONRECIPIENTS$"
}{code}
# Go to *Configuration* > *NoMa*.
# From the Notifications tab, select the&nbsp;*Create*&nbsp;button to add a new notification rule, or to edit select the _pencil_ icon corresponding to an existing rule.
# On the next screen, enter the notification information (the directives are described in the table below), then select *Create*/*Save*.
\\
\\
Table: Notification rule directives
| Notification Information | *Name* \- Identifies the notification and is displayed on the _Notifications_ front page. \\
*Description* \- Optional notification description. \\
*Activated* \- If checked means the notification is enabled, (a notification rule can also be enabled from the Manage Notification Rules page). \\
*Owner* \- Identifies the _owner_ of a rule and allows the user to edit his own rules, administrators can edit rules of every user. |
| Hosts and Services (comma-separated) | *Includes and Excludes* \- Indicates which *hosts*, *host groups*, *services*, *service groups* and *recipients* are to be included or excluded in the notification rule. 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 [Filter Examples|#filterexamples] documented at the end of this page. \\
*Wildcard* \- The " * " 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. \\
*Hosts and Services* \- For _Hosts_ and _Services_ fields, typing a host name and pressing _Tab_ will display a list of valid hosts and services. |
| Contacts and Methods | *Contacts* \- Selected contact(s) will be notified. \\
*Groups* \- Selected contact group(s) will be notified. \\
*Methods* \- Selected method(s) will 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. \\ |
| Timezone and Timeframe | *Timezone* \- Selected time zone is used for the notification (e.g., America/Los_Angeles). \\
*Timeframe* \- Selected timeframe indicates hours allowed for notifications to be sent, (e.g., 24x7). |
| Which events to notify | The *checked* filter options specifically define the recovery, problem, state transitions, and other states of change for which to send notifications. \\ |
| Numbers and more | *Notify after* \- Sets the _notify after_ number indicating when notifications will start being sent. \\
*Rollover if the last rule is reached* \- If checked, enables NoMa to start again at number 1 when the last notification has been reached. If unchecked, NoMa stops notifying when the last notification/escalation has been reached. \\
*Let notifier handle escalations* \- If checked, enables NoMa to simulate the reception of notifications from Nagios and is useful for one-off alerts. \\ |
| Add Escalation | Used to define escalations for the notification rule. Continues notifications after specified _notify after_ directive. |
# The escalations option is only displayed for previously defined notification rules. To add an escalation, make sure to save the notification rule, then go back to *Configuration* > *NoMa*&nbsp;>&nbsp;*Notifications*, and select the&nbsp;*pencil*&nbsp;icon corresponding to the rule to update.
# Then, select&nbsp;*add Escalation* toward the bottom of the screen.
# Next, select the *Contacts* and or *Groups* for the escalation, those to be notified, and the *Methods* of communication. The *Notify after* number indicates when this notification should be escalated.&nbsp;An element in each of the&nbsp;_Contacts_,&nbsp;_Groups_, and&nbsp;_Methods_&nbsp;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_&nbsp;keys while making a selection.

| Let's set up the host and service notify to NoMa commands: \\
* Go to *Configuration* > *Commands* > *New*, click *Next >>*.
* Enter the command name as *host-notify-by-noma*, select a notification type *notify*, and copy and paste the above host definition in the space for *Command line* editing the "*/path to noma/*" appropriately (*/usr/local/groundwork/noma/notifier/*).
* Select *Add* to save, and repeat the process for the service command. | Figure: Create host-notify-by-noma command \\ !8.jpg|border=1! \\
Figure: Create service-notify-by noma command \\ !9.jpg|border=1! |
| In Nagios/Monarch we will need to add/edit the contact to be associated with the forwarding of the alerting. \\
* In our lab we are going to 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 this contact.
* Then you will need to make sure that all hosts are setup with the *nagiosadmin* contact group. | Figure: Associating NoMa Script\\
!10.jpg|border=1! |
h4. 2.2 NoMa Commands

h5. 4.2 Activating notifications
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.

| Let's activate the *entire network* notification. \\
* Check the activate/deactivate icon (*check mark*) to make the check green. | Figure: Activating Notifications for a Defined Notification\\
!12.jpg|border=1! |
| * You will need to verify that notifications in Nagios are enabled, see *Configuration* > *Control* > expand *Nagios main configuration*, select *Notification* and verify the box is checked for *Enable notifications*. | Figure: Enabling Notifications via Nagios/Monarch\\
!13.jpg|border=1! |
{warning}The following updated commands are included in the GroundWork Monitor 7.2.0 release. Administrators should check existing commands and update if necessary for prior versions of GroundWork Monitor.{warning}

h4. 5.0 Receiving Notifications, Viewing Logs
* {{host-notify-by-noma}}
{{/usr/local/groundwork/noma/notifier/alert_via_noma.pl \-c h \-s "$HOSTSTATE$" \-H "$HOSTNAME$" \-G "$HOSTGROUPNAMES$" \-n "$NOTIFICATIONTYPE$" \-i "$HOSTADDRESS$" \-o "$HOSTOUTPUT$" \-t "$TIMET$" \-u "$$(( $HOSTPROBLEMID$ ? $HOSTPROBLEMID$ : $LASTHOSTPROBLEMID$ ))" \-A "$$(\[ \-n "$NOTIFICATIONAUTHORALIAS$" \] && echo "$NOTIFICATIONAUTHORALIAS$" \|\| echo "$NOTIFICATIONAUTHOR$")" \-C "$NOTIFICATIONCOMMENT$" \-R "$NOTIFICATIONRECIPIENTS$"}}

| * Notification alerts should start arriving via our *Notify by E-mail* setting defined previously in the notification setup.
* Our sample notification email here shows the host *gw-logstash-02* service *http_alive* in a *CRITICAL* state. The *Link:* is active and can take you directly into the *Status* application for this device where you can acknowledge and or apply actions. | Figure: Example Notification Email\\
!14.jpg|border=1! |
| * You can browse through your notifications including defined escalations with in the *Logs* option from the main NoMa menu.
* The boxes at the top of the list enable you to filter by content of any of the columns, for instance you can enter *Check type* "service" to filter by only *Service* or enter a *recipient's name* to filter by a specific notification recipient. | Figure: Notification Logs\\
!15.jpg|border=1! |
* {{service-notify-by-noma}}
{{/usr/local/groundwork/noma/notifier/alert_via_noma.pl \-c s \-s "$SERVICESTATE$" \-H "$HOSTNAME$" \-G "$HOSTGROUPNAMES$" \-E "$SERVICEGROUPNAMES$" \-S "$SERVICEDESC$" \-o "$SERVICEOUTPUT$" \-n "$NOTIFICATIONTYPE$" \-a "$HOSTALIAS$" \-i "$HOSTADDRESS$" \-t "$TIMET$" \-u "$$(( $SERVICEPROBLEMID$ ? $SERVICEPROBLEMID$ : $LASTSERVICEPROBLEMID$ ))" \-A "$$(\[ \-n "$NOTIFICATIONAUTHORALIAS$" \] && echo "$NOTIFICATIONAUTHORALIAS$" \|\| echo "$NOTIFICATIONAUTHOR$")" \-C "$NOTIFICATIONCOMMENT$" \-R "$NOTIFICATIONRECIPIENTS$"}}

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.&nbsp;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.,&nbsp;*nagiosadmin*). You may want to create a new contact and contact group.
# Go to *Configuration* > *Contacts* > *Contacts* >&nbsp;*Modify*, and select the contact to modify, (e.g.,&nbsp;_nagiosadmin_).
# Set the _Host notification commands_ box to *host-notify-by-noma* and the _Service notification commands_ box to *service-notify-by-service*.
# Scroll down and set&nbsp;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.jpg|thumbnail!

h4. 2.3 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&nbsp;*Commit*&nbsp;and follow the process to commit the configuration change.
\\
\\
Figure: Enable notifications
\\ !bookshelf_03_how_to_configure_notifications_using_noma.jpg|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.jpg|thumbnail!\\
\\
# Notifications will then be sent based on the directives set in the notification rule.&nbsp;The notification example email below shows the host *ad-demo*&nbsp;service *windows-net*&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.
\\
\\
Figure: Example NoMa email notification&nbsp;
{noformat}***** NoMa *****
ID: 7
Notification Type: PROBLEM
Service: windows_net
Host: ad-demo
Host Alias: ad-demo
State: CRITICAL
Address: 172.28.111.16
Link: [http://docs.groundwork.groundworkopensource.com/portal-statusviewer/urlmap?host=ad-demo&service=windows_net|http://docs.groundwork.groundworkopensource.com/portal-statusviewer/urlmap?host=ad-demo&service=windows_net]
Info: A valid MODE and/or SUBMODE must be specified

Date/Time: Thu Aug 24 08:53:29 2017{noformat}
# The *Logs* tab displays NoMa notifications in a log 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.
\\
\\
Figure: NoMa notification log
\\ !bookshelf_05_how_to_configure_notifications_using_noma.jpg|thumbnail!


h1. 3.0 Examples
{anchor:filterexamples}

h4. 3.1 How Filters Work

Following is an example notification rule with host configuration for two hosts, applied filters, and the notification results.

h6. Host Configuration

| | Host 1 | Host 2 |
| Host | mysql-lnxsrv01 | mysql-lnxsrv02 |
| Hostgroup(s) | mysql, linux-servers | mysql, linux-servers |
| Servicegroup(s) \\ | mysql-svcs \\ | mysql-svcs \\ |
| Service (desc) \\ | MySQL Service \\ | MySQL Query Cache Hitrate \\ |

h6. Host and Services Filters

| | Includes | Excludes |
| Hosts | | |
| Hostgroup | {color:#ff6600}mysql{color} | |
| Servicegroup | {color:#ff6600}mysql-svcs{color} | |
| Service | | {color:#3366ff}mysql query\*{color} |

h6. Notification Results

For Host 1 the rule matches and the notification is sent. For Host 2 the rule does not match and the notification is not sent to members of this notification rule.

| | Host 1 | Host 2 |
| Host | | |
| Hostgroup | {color:#ff6600}Matches include{color}\\ | {color:#ff6600}Matches include{color}\\ |
| Servicegroup | {color:#ff6600}Matches include{color}\\ | {color:#ff6600}Matches include{color}\\ |
| Service | | {color:#3366ff}Matches exclude{color}\\ |
| Notification sent? | Yes \\ | No \\ |