Notification Settings
Knowing the status of the monitored infrastructure is the first step to solve or prevent possible incidents. WOCU-Monitoring has a configurable notification system that notifies the operator of the results of operational checks carried out, in order to act promptly in the event of incidents and thus minimise their impact or occurrence.
This is possible by defining different Time Periods for notification as part of the configuration of Hosts, Services and Contacts. The flexibility offered by this system allows it to adapt to the needs and preferences of the operator, ensuring effective communication about any important situation that requires their attention.
Ultimately, the operator will be able to define new notification paths, establishing specific time periods or intervals in which the system will send notifications when relevant events occur. These events may include availability problems, downtime or recovery of Hosts and Services, in short, status changes.
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, divided into two time slots:
1st: 09:00 - 14:00 h.,2nd: 15:00 - 18:00 h..Scope: Hosts and Services in DOWN/CRITICAL status.
Means of notification: Slack.
For this purpose, the process is divided into four parts:
1. Creation of a Notification Command
These commands specify how notifications are sent via communication tools or technologies that WOCU-Monitoring integrates and supports.
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 module and go to the Active Assets > Contacts > Notifications Command section.
1.2 Creating a new command for Hosts
Click on the + Add Notification Command button and select the
Notify by slackoption.
Enter the following data in the configuration form:
a. Notification Name: agregue el término identificador del comando:
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 Notification Command button and select the
Notify by slackoption.
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, the command will be configured within Notifications Ways which will be associated to as many contacts as desired.
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 on the button + Add Notification way.
Enter the following data 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 shortcut Working schedule and set a first time frame that starts (Start Time) at 09:00 h. and ends (End time) at 14:00 h.
Next, add a new time frame using the New Schedule button. Repeat the selection of the shortcut Working schedule, and finally, define a second period starting (Start Time) at 15:00 h. and ending (End time) at 18:00 h.
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_Hostcommand for the system to issue notifications through the Slack application. This option has been created in step: 1. Creation of a Notification Command.
e. Service notification schedule: select the shortcut Working schedule and set a first time frame starting (Start Time) at 09:00 h. and ending (End time) at 14:00 h.
Next, add a new time frame using the New Schedule button. Repeat the selection of the shortcut Working schedule, and finally, define a second period starting (Start Time) at 15:00 h. and ending (End time) at 18:00 h.
f. 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.
g. Service notification commands: select the
Slack_Servicescommand for the system to issue notifications via the Slack application. This option has been created in step: 1. Creation of a Notification Command.
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 Access to the Contacts section
To link notification periods to a Contact, access the Configuration module and go to the Active Assets > Contacts section.
3.2 Location of the relevant contact
In the global listing of Contacts, locate
User_1. This will be the future recipient of notifications.
To edit the Contact settings, click on the name of the Contact.
Next, the Contact
User_1profile 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 is confirmed using the Save button, the new notification settings will be assigned to the Contact, with the relevant notifications from Hosts and Services associated to it.
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.
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. |