Create an Alert Policy¶

Create¶

1. Define a name for the current Alert Policy.
2. Optionally enter a description for this Alert Policy.
3. Select the Associated Monitors.
4. Select the notification time zone.
5. Select an Alert Policy based on Severity or Member to configure notification triggers.
6. Select the time range for Repeat Alerts (Original Alert Muting).
7. Optionally select the Alert Aggregation mode to determine the final aggregation form of alert notifications.
8. Optionally add Operation Permissions for the policy rules.
9. Save to complete the creation.

Associated Monitors¶

On the configuration page, you can click to select monitor rules associated with the current Alert Policy, including:

• All
• Monitor
• Smart Monitoring
• SLO
• Security Monitoring

Here you can quickly create new monitor rules as needed.

Configure Notification Rules¶

Two notification configuration modes are supported:

By Severity: After selecting an event severity, set notification targets for this type of anomaly event. If Filter Conditions are configured, further restrict the event data scope under a severity, and finally send notifications to the targets.

By Member: First select members or teams, define the event data scope they need to focus on or own, and within this data scope, determine the event severity levels and corresponding notification targets, achieving a strong association between events and targets.

Severity-Based Notification Configuration¶

Define the notification targets for alerts at each severity level.

1. Select the Event Severity.

   • A severity level can be selected multiple times.

   • Based on the selected event severity, you can also link Alert Aggregation.

2. Select the targets that should receive notifications for events at this severity.

Member-Based Notification Configuration¶

By configuring notification rules based on members, you can achieve precise point-to-point alert notifications. In one alert rule, you can configure different notification scopes, severity levels, and methods for multiple member groups, and customize notification time ranges for these member groups.

1. Define a name for the notification rule.
2. Select the members and teams to be notified.
3. Add filter conditions to match tags.
4. For the filtered event data, set corresponding notification targets for different event severity levels.
5. Optionally enable the Custom Notification Time Range configuration.

Add Filter Conditions¶

Whether you configure notifications by severity or by member, adding specific filter conditions allows you to:

• For severity-based notifications, further narrow the data scope of events at a specific severity.

• For member-based notifications, limit members or teams to focus only on events that match specific tags.

After adding filters, only events that meet both the severity requirements and the filter conditions trigger notifications.

In Configure Notification Rules of the Alert Policy, click Filter, select common fields such as Host, Kubernetes, and Application Service, and set matching values. You can also manually enter event fields to restrict the event scope for notifications in the key:value format.

For example, use service and env to filter events for a specific service and environment. Field names and values can be viewed in Event Details.

Equal, Not Equal, Wildcard, Wildcard Negation, and Regex Match are supported. Multiple conditions on the same field are matched with OR, and conditions on different fields are matched with AND.

Alert Escalation Notifications¶

If a Monitor frequently detects anomalies at the same severity within a short period, it may indicate a persistent issue. In this case, other notification targets may be needed to resolve the issue. You can add escalation notification rules so that, when the anomaly persists, the system automatically escalates it to a critical notification and sends it to the specified recipients, ensuring that the issue is noticed and handled promptly.

If a notification rule has two escalation notifications configured:

• When alerts of the same severity continue to be generated, the system checks the time interval to determine whether to send the first escalation notification.

• After the first escalation notification is sent, the system checks the interval configured for the second escalation notification to determine whether to send the second one.

Custom Notification Time¶

The scenarios discussed above focus on sending notifications immediately when anomalies are detected. In fact, you can also define specific times for sending notifications as needed.

1. Optionally modify the configuration name.

2. Define the cycle to which events belong by day, week, month, or custom.

   • If Custom is selected, upload a CSV file, and the system automatically fills in the dates listed in the file. (❗️The dates in the file must use the YYYY/MM/DD (year/month/day) format; no more than 365 dates are allowed in the file.)

3. Use the cycle to limit the time of day during which events are generated, and send notifications according to the selected time range. For example, if 09:00 - 10:00 is selected, after the policy takes effect, anomaly events generated within this hour are matched and routed to this custom configuration.

4. After completing the cycle and time settings, select the alert severity level and notification targets.

Repeat Alerts¶

After you configure Repeat Alert notifications, event data continues to be generated within a certain time range, but no alert notifications are sent. The generated event records are stored in the Event Explorer.

Configure Repeat Alerts by Severity¶

After enabling this option, you can configure the interval during which repeat alert notifications are not sent for different alert severity levels (such as Critical, Major, and Warning).

This setting applies only to the selected alert severity levels: alerts at the selected levels will not send repeat notifications within the configured interval, while unselected levels continue to follow the original repeat alert notification rules.

Advanced Configuration¶

Do not send notifications for recovery events: After enabling this option, all recovery conditions only generate events and do not send notifications.

Configure Alert Aggregation Rules¶

No Aggregation¶

The default configuration. In this mode, alert events are grouped into one notification every 20 seconds and sent to the corresponding notification targets.

Rule Aggregation¶

In this mode, you can select the following aggregation rules and send alert notifications based on the aggregation period:

Trigger Policy¶

In Rule Aggregation mode, if Send First Alert is selected, df_status is additionally appended on top of All, Monitor/Intelligent Inspection/SLO, Detection Dimension, and Tags when alert notifications are sent, so that important anomaly events are not missed while waiting for aggregation.

Smart Aggregation¶

In this mode, events generated within the aggregation period are clustered into groups based on the selected Title or Content, and each group generates one alert notification.

AI Aggregation¶

Uses a large language model to aggregate new events into one alert within the specified number of minutes. When the timeout is reached, the next alert is generated automatically, avoiding repeated interruptions.

Custom¶

Flexibly specify a combination of specific fields for alert aggregation based on actual business needs. You can enter one or more field names, and the system strictly aggregates alerts according to the field combination you specify. Only when event data contains all specified fields and each field has a valid value will an aggregation alert based on these fields be triggered.

Separate fields with commas, for example: host, source, service_name; a single field (for example, host) or a combination of multiple fields is supported.

If you specify two fields such as host, source, but some events contain only host and lack source, these events will not be aggregated.

Aggregation Period¶

In Rule Aggregation and Smart Aggregation modes, you can manually set an aggregation period (between 1 and 30 minutes).

Within this period, new events are aggregated into one alert notification and sent. If the aggregation period is exceeded, new events are aggregated into a new alert notification.

Configure Operation Permissions¶

After you configure operation permissions for an Alert Policy, roles, team members, and workspace users in the current workspace can perform corresponding operations on the Alert Policy based on the assigned permissions. This ensures that different users can perform operations according to their roles and permission levels as configured.

• If this option is not enabled: Follows the default permissions of Alert Policy Configuration Management.

• If this option is enabled and custom permission targets are selected: Only the creator and the assigned permission targets can enable/disable, edit, or delete the rules configured in this Alert Policy.

• If this option is enabled but no custom permission target is selected: Only the creator has enable/disable, edit, and delete permissions for this Alert Policy.

Further Reading¶