EV Observe - Notification Policy
Notifications are used to inform a contact or group of status changes in a configuration item (CI), i.e. host, service or user service.
- Notifications can be sent:
- Based on the business impact of the change in status or warning.
- Once there is a change in status or once controls have been repeatedly run.
- During notification periods.
- They can be sent via email, SMS, voice call (business option) or push email (mobile app). They can also be sent to a Teams team and logged in the syslog file.
- If the status is not acknowledged by the operations team, this will trigger the escalation process and notifications will be sent to successively higher levels.
Notification and escalation policies
Notification policy
- The notification policy consists of defining the trigger events and their status changes, the notification periods, the contacts and groups to be informed and the notification channels, for each configuration item (CI).
- Notification settings are defined for both contacts and configuration items (CI), i.e. host, service or user service.
Escalation policy
- The level 1 escalation policy consists of sending notifications to contacts or groups of contacts when there is an incident with a CI. Once the warning is acknowledged by a level 1 contact, notifications will stop and the escalation process will be interrupted.
- If the warning is still not acknowledged after the number of controls defined in the CI have been run, the issue will be escalated and notifications will be sent to level 2 contacts or groups. If it is still not acknowledged, it will be escalated to level 3 contacts and groups. Once the warning is acknowledged by a contact of that level, notifications will stop and the escalation process will be interrupted.
Examples
Implementation of a notification policy for the COPCGRE61 server:
- Notification timeslots defined:
- 24-hour period defined for the COPCGRE61 server
- From 5 am to 12 noon for team A (defined in the group of contacts)
- From 12 noon to 8 pm for team B (defined in the group of contacts)
- An incident occurs on the server:
- Warning at 10 am: Notification sent to team A.
- Warning at 1 pm: Notification sent to team B.
- Warning between 8 pm and 5 am: No team is informed. If the incident is still present at 5 am, a notification will be sent to team A.
Implementation of an escalation policy for the COPCGRE61 server:
- 24/7 notifications sent to the Level 1 On-call group.
- If an incident occurs on the host, notifications will be sent to the On-call group every three minutes.
- Once the warning is acknowledged by a member of the On-call team, notifications will stop and the escalation process will be interrupted.
- If the warning is still not acknowledged after 15 minutes, this will trigger an escalation to the Level 2 On-call managers group who will receive notifications.
Notes
- Only active contacts and groups of contacts will receive notifications.
- When the state of the CI is unstable, notifications will be disabled to restrict the number of warnings triggered. They will remain disabled until the state of the service is once again stable.
- You must first configure the notification policy for the CI (host or service only) before you can configure the escalation process.
- To send notifications to a Teams team, you must first create a notification channel associated with an incoming webhook. Information is exchanged between EV Observe and Teams using the webhook URL.
See Configure the Teams notification channel
Best Practice
- Use the Modify the notification policy wizard or the Update the notification escalation policy wizard to apply the same policy to an entire group of CIs.
example Define a single notification policy for all servers whose business impact is High
- You can view the instability rate of a CI in real time in the General information tab of the CI Details form (Monitoring > Monitoring menu).
Procedure: How to define a global notification policy for a customer company
Step 1: Select the company where you want to implement the notification policy
SelectCompanyInCompanyTree_Procedure
1. Go to the Web app.
2. Select the company from the company tree structure.
Notes:
- The selected company must be associated with a Box.
- You can create a new company. See the procedure
Step 2: Define the notification timeslots
1. Select Configuration > General > Timeslots in the menu.
2. Create and configure all notification, monitoring and availability timeslots to be applied to the company's configuration items (CI).
See the description
Step 3: Define the contacts and groups of contacts to be notified
Contacts
1. Select Configuration > General > Contacts in the menu.
2. Create and configure all contacts to be notified in the company.
- Select the Enable: Yes option.
- Specify the types of notification that the contact can receive and define the contextual properties specific to each category, e.g. status changes, notification channels, notification periods, information to be logged in the syslog file.
See the description
If the contact is receiving notifications via a Teams team, you must first create a notification channel associated with an incoming webhook in Teams. Next, specify the Teams Webhook URL field.
Groups of contacts
1. Select Configuration > General > Groups of contacts in the menu.
2. Create all groups of contacts and associate contacts with the groups.
Step 4: Define the global notification policy for the company
Use the Modify the notification policy wizard or the Update the notification escalation policy wizard to apply the same policy to an entire group of CIs.
Step 4.a: Define the notification and escalation policies for hosts
1. Select Configuration > Hosts > List in the menu.
2. Open the relevant Host configuration form.
3. Define the notification policy for the host.
- Select the Notifications tab.
- Select the Enable Notifications: Yes option.
- Select the notification period, tick the status changes that will trigger notifications and specify the level 1 contacts and groups to be notified.
See the description
4. Define the escalation policy for the host
- Select the Availability and checks tab and specify the general information on the control, i.e. host monitoring timeslot, interval between two controls, number of times the control is repeated before sending the first notification.
See the description
- Select the Escalations tab and specify the contacts and groups to be notified if a status is not acknowledged by the lower-level operations team.
See the description
Step 4.b: Define the notification and escalation policies for services
1. Select Configuration > Services > List in the menu.
2. Open the relevant Service configuration form.
3. Define the notification policy for the service.
- Select the Notifications tab.
- Select the Enable Notifications: Yes option.
- Select the notification period, tick the status changes that will trigger notifications and specify the level 1 contacts and groups to be notified.
See the description
4. Define the escalation policy for the service.
- Select the Availability and checks tab and specify general information on the control, service monitoring timeslot, interval between two controls, number of times the control is repeated before sending the first notification.
See the description
- Select the Escalations tab and specify the contacts and groups to be notified if a status is not acknowledged by the lower-level operations team.
See the description
Step 4.c: Define the notification and escalation policies for user services
1. Select Configuration > User Services in the menu.
2. Open the relevant User Service configuration form.
3. Define the notification policy for the user service.
- Select the Notifications tab.
- Select the Enable Notifications: Yes option.
- Select the notification period, tick the status changes that will trigger notifications and specify the level 1 contacts and groups to be notified.
See the description