Notification Settings

Knowing the status of the monitored infrastructure is the first step in resolving or preventing potential incidents. WOCU-Monitoring has a configurable notification system that alerts the operator about the results of operational checks performed, enabling them to act quickly in the event of incidents and thus minimize their impact or occurrence. The flexibility offered by this system allows it to adapt to the operator’s needs and preferences, guaranteeing effective communication about any important situation that requires their attention.

Ultimately, the operator will be able to define new notification channels, establishing specific periods or time intervals during which the system will send notifications when relevant events occur. These events may include availability issues, crashes or recovery of Devices and Services, and ultimately, changes in state.

The space of time not covered by the established configuration will be treated as periods of inactivity (for warning purposes), thus minimising the noise of unnecessary notifications and eliminating the feeling of excess information, which has an impact on the loss of confidence in the alarms obtained. For example, in maintenance tasks with scheduled stops and outages.

Use case

This use case details the process of configuring and programming a new notification way (Notification Way) based on the following criteria:

• Time period subject to notifications: Monday to Friday, structured in two time slots: from 9:00 a.m. to 2:00 p.m. and from 3:00 p.m. to 6:00 p.m.

• Scope: Hosts and services that remain in a DOWN or CRITICAL state for at least 10 minutes.

• Means of notification: Slack.

For this purpose, the process is divided into four parts:

1. Creation of a Notification Command.

2. Creation of Notification Way: periods, typology and dispatching.

3. Associate the new notification channel to the Recipient Contact..

4. Receiving alarms in Slack.

1. Creation of a Notification Command

These commands define the method for sending notifications using the various communication tools or technologies that WOCU-Monitoring integrates and supports. Their purpose is to ensure that the alerts generated by the system are transmitted efficiently, promptly, and according to the configured communication channels.

For this use case the means of notification shall be: Slack.

1.1 Access to the Commands section

For command definition and configuration, access the Configuration > Active Assets > Contacts > Notifications Command section.

1.2 Creating a new command for Hosts

• Click on the + Add button and select the Notify by slack option.

• Enter the following data in the configuration form:

  

  a. Notification Name: Add the command identifier term: Slack_Host.

  b. Assets type: select the Host option from the drop-down.

  c. Slack Channel: register the name of the channel in Slack that will receive the relevant notifications: #wocu-wow.

  d. Slack Webhook: register the URL: https://hooks.slack.com/services/TOKEN. Important: request the Webhook object from your Slack administrator. More information on the following link.

1.3 Creating a new command for Services

• Click on the + Add button and select the Notify by slack option.

• Enter the following data in the configuration form:

  

  a. Notification Name: add the command identifier term: Slack_Services.

  b. Assets type: select the Services option in the drop-down.

  c. Slack Channel: register the name of the channel in Slack that will receive the relevant notifications: #wocu-wow.

  d. Slack Webhook: register the URL: https://hooks.slack.com/services/TOKEN. Important: request the Webhook object from your Slack administrator. More information on the following link.

Once created, this command will be configured within a Notification Way, which can then be associated with one or more contacts as needed. Continue reading the use case to learn how to perform this configuration.

2. Creation of Notification Way: periods, typology and dispatching

2.1 Access to the Notifications Ways section

For the definition and configuration of notification periods, access the Configuration module and go to the Active Assets > Contacts > Notifications Way section.

2.2 Creation of a new notification channel

• Click the + Add button and enter the following information in the configuration form:

  

  a. Notification name: add the term identifying the notification path: working time period.

  b. Host notification schedule: set the time frame subject to notifications.

  For this use case, select the quick access :guilabel:Working schedule and configure a first time frame that starts at 9 hours (Start Hours Time) and 00 minutes (Start Minutes Time) and ends at 14 hours (End Hours Time) and 00 minutes (End Minutes Time).

  Next, add a new time frame using the :guilabel:New Schedule button. Repeat the selection of the quick access :guilabel:Working schedule, and finally define a second period that starts at 15 hours (Start Hours Time) and 00 minutes (Start Minutes Time) and ends at 18 hours (End Hours Time) and 00 minutes (End Minutes Time).

  Please note that the period of time not covered by the current configuration will be treated as periods of inactivity for warning purposes.

  

  c. Host notification options: configure in which events to generate a notification. For this use case, the aim is to receive alerts when the Hosts register a DOWN status. To do so, select the checkbox corresponding to the option: Notify on DOWN host states.

  

  d. Host notification commands: select the Slack_Host command for the system to issue notifications through the Slack application. This option has been created in step: 1. Creation of a Notification Command.

  

  e. Host down notification delay (minutes): en este campo se define el tiempo de espera (expresado en minutos) que el sistema considerará antes de enviar una notificación cuando un dispositivo registre un estado de monitorización DOWN. Para este caso de uso, introduzca el valor 10.

  f. Service notification schedule: select the quick access Working schedule and configure a first time frame that starts at 9 hours (Start Hours Time) and 00 minutes (Start Minutes Time) and ends at 14 hours (End Hours Time) and 00 minutes (End Minutes Time).

  Next, add a new time frame using the :guilabel:New Schedule button. Repeat the selection of the quick access :guilabel:Working schedule, and finally define a second period that starts at 15 hours (Start Hours Time) and 00 minutes (Start Minutes Time) and ends at 18 hours (End Hours Time) and 00 minutes (End Minutes Time).

  

  g. Service notification options: configure in which events to generate a notification. For this use case, the aim is to receive alerts when the Services register a DOWN status. To do so, select the checkbox corresponding to the option: Notify on CRITICAL service states.

  

  h. Service notification commands: select the Slack_Services command for the system to issue notifications via the Slack application. This option has been created in step: 1. Creation of a Notification Command.

  

  i. Service critical notification delay (minutes): in this field, the waiting time (expressed in minutes) that the system will consider before sending a notification when a service registers a CRITICAL monitoring status is defined. For this use case, enter the value 10.

  Note

  More information about the different configuration fields can be found at: Add Notification.

  Finally, confirm the new notification path defined via the Create button.

2.3 Display of the notification path

A new notification method called working time period is now available in the global listing of Notifications Ways.

3. Associate the new notification channel to the Recipient Contact.

In this step, the linking of notification channels is addressed as part of the Contacts configuration.

3.1 Locating the relevant contact in the Contacts section

• To link notification periods to a Contact, access the Configuration module and go to the Active Assets > Contacts section.

• In the global list, locate the contact that will receive future notifications. For this use case, the contact User_1 is used.

• To edit the Contact settings, click on the name of the Contact.

• Next, the Contact User_1 profile will pop up, with the Edit option heading the view.

• Once in the edit form, position on the Notification ways attribute, expand the tab and select the notification way working time period. This option has been created in step: 2. Creation of Notification Way: periods, typology and dispatching.

• Once the change has been confirmed using the Save button, the new notification configuration will be assigned to the contact User_1, with the relevant alerts coming from the Devices and Services associated with them.

Note

If you wish to add a new Contact, you can do so from the Add Contact action, located in the Contacts section.

In this case, once the new profile is created, it must be linked to an asset in order to be able to log and report the relevant incidents that occur. This can be done manually in the configuration of each asset, or by assigning Templates. In both situations, there is the Contacts attribute to establish the asset/contact relationship.

4. Receiving alarms in Slack

In this final step, the integration of WOCU-Monitoring with Slack for real-time notification of specific events is addressed. It will be up to the WOCU-Monitoring and Slack administrator to make some preliminary configurations.

In particular, it will be necessary for the administrator to provide access to the enabled notification channel and to set the webhook variable to consolidate the connection between the two tools. More information can be found at the following link.

4.1 Receiving and managing notifications in Slack

In this use case, the Slack administrator has created the #wocu-wow channel where notifications are received. In it, the different alerts that fit the established criteria (time periods and marked scope) are listed.

According to the current use case, two notifications can be observed for each type of asset: Host Host_LML and Service Http. In both examples there has been a total loss of availability, registering a Down/Critical monitoring status.

At this point, the user is aware of the incident and can proceed to resolve it in order to minimise its impact.

Types of notifications

In the process of setting up notifications, it is essential to consider carefully consider the specific type of notification you are managing. The NOTIFICATION TYPE field plays a key fundamental role in identifying the nature of the notification in question.

By having a clear understanding of the different types of notifications, the operator can optimise event management and ensure that system responses are precisely aligned with the monitoring monitoring needs of their environments.

The table below presents the different notifications, along with detailed descriptions of each.

Types of notifications

Type	Description
PROBLEM	This typology indicates that there is an anomaly with a monitored asset by WOCU-Monitoring. When it comes to a service, it may refer to a change in availability status to Warning, Unknown, or Critical. If it concerns a device, the possible states are Down or Unreachable.
RECOVERY	Indicates the recovery of availability for a monitored asset, becoming accessible again after experiencing some form of interruption previously. When it comes to a service, it means it has just returned to an OK state. If it concerns a device, it has just registered an UP state.
ACKNOWLEDGEMENT	This typology refers to the acknowledgment that the operator is awareof an issue recorded in a monitored device or service. Acknowledgments are generated through the web interface by contacts designated for that particular asset. In other words, when someone responsible for monitoring detects an incident, they can confirm through the web interface that they are aware of the situation, and this notification serves as a record of that acknowledgment.
FLAPPINGSTART	It means that a device or service has just recorded a flapping state, indicating that it is experiencing frequent and rapid changes in its operational status, suggesting instability in the availability of the asset in question.
FLAPPINGSTOP	It means that a device or service has stopped exhibiting flapping behavior. In other words, the asset has stabilized. This can be a positive indicator, as stability in the operational state facilitates the identification and resolution of potential issues.
FLAPPINGDISABLED	It indicates that the flapping state has been intentionally deactivated for the device or service in question, implying that no alert will be generated when there are frequent changes in its status. This could be useful in specific situations where temporarily disabling fluctuation detection is preferred, for example, during maintenance or when it is expected that the state will change frequently without being a cause for concern.
DOWNTIMESTART	Indicates that a device or service has started a scheduled period of inactivity. During this time, the asset is expected to be unavailable or out of service due to planned activities, such as maintenance. To prevent the generation of unnecessary notifications or unwanted alarms during this defined time window, future notifications are suppressed.
DOWNTIMESTOP	Indicates that a device or service has concluded a previously scheduled period of inactivity, and the alerting of events is resumed. During this period, notifications regarding any issues or irregularities in monitored assets were suspended.
DOWNTIMECANCELLED	Indicates that the scheduled downtime period for a device or service has just been canceled. Notifications about issues can now be resumed.