Notifications and Triggers > Alert Notification Customization

Alert Notification Customization

Standard alert notifications include details like a summary, description, event duration, metric values, and historical data. However, users often need additional context about the affected components and metrics.

Adding Additional Fields to the Metric Information

For instance, when reporting CPU usage on a server, users might want the notification to include the server’s location, the server’s operating system, and the name of the application using it.

Information Rules

These rules provide contextual information when alarm notifications are generated. For example, if a high CPU usage notification occurs, users can receive a list of the top processes consuming CPU. Likewise, when a notification reports a low success rate for an e-commerce application, users can receive the top reasons for failures to pinpoint the problem area. In all such cases, Information Rules can be applied to the alert rule. Your first rule monitors system CPU usage using the hostname as a grouping level. Then, you have a second information rule that identifies the top CPU-consuming processes, and it uses both the hostname and process ID for grouping.

Using Multiple Information Rules

Feel free to add as many information rules as needed to enhance your alert notifications. Just remember to include at least one primary rule that specifies how to detect the alert condition.

Adding Contextual Information

To provide additional information in alert notifications, such as a list of the top processes consuming CPU when receiving a high CPU usage alert, you can utilize information rules. Please check the Information Rules section for more details.

Remove Metric From Contextual Information Of An Alert

When you have multiple rules specified in an alert configuration, the results from each rule will typically be included in the alert notification.  However, there are situations where you might want to exclude results from some rules in the notification.  For instance, if you have an alert rule checking for low transaction volume and another condition for stream processing lag (Kafka), you might want to generate alerts for low transaction volume only when Kafka lag is below a certain threshold.  This can be achieved through Evaluation Script advanced configuration settings. You can accomplish this by clearing the entire rule dictionary for a specific rule from the D array after performing the necessary operation. In this example, we’ve added the lag Data Model as R2. This helps customize the alert notifications to include only the relevant information you want to see.
if R1 and R2:     D[1][‘Eazypay Lag – Alert’] = {}  #empty the R2 from D Array     RESULT = True

Sending Periodic Updates If The Alarm Condition Persists

You can send periodic updates when the alarm condition persists for an extended time by configuring specific channels for these reminders.  In the advanced configuration settings, you’ll find separate options for each channel where you want to send these updates. This feature helps keep operators informed with regular reminders when an alarm condition remains active for a prolonged duration.
Channel Configuration
Email Channel EmailAlerterUpdate
SMS Channel SmsAlerterUpdate
WhatsApp Channel WhatsappAlerterUpdate
Microsoft Teams Update TeamsAlerterUpdate
Slack Channel Update SlackAlerterUpdate
For example, if update notification emails are required every 30 minutes if the alarm condition persists, the following configuration is to be specified in Advanced Configuration.
EmailAlerterUpdate: 30
The above configuration would result in periodic updates every 30 minutes if the alarm is active.

Sending a Trigger Update on Email, SMS, WhatsApp, Slack, and Teams

In alarm mode, email notifications are sent when the alarm becomes active and when it gets cleared. Additionally, an update notification email is sent when the alarm’s severity changes to keep operators informed. But in some cases, you might want to send an update notification when specific conditions are met.  For example, you can configure an update notification email to be sent when the transaction count exceeds a certain threshold beyond what’s specified in the alert rule.  This allows for more customized notifications when certain criteria are fulfilled.
If R1:     # Alert is active based on the threshold configured in the rule       vol = get_DM_value(D, 1, ‘success_rate’)       If vol > 100000:         META_DATA[‘force_update] = True


Browse through our resources to learn how you can accelerate digital transformation within your organisation.

Unveiling our all powerful Internet and Mobile Banking Observability Experience Center. Click Here