Managed Service for Prometheus:Notification policies

Create a notification policy

1. Log on to the Managed Service for Prometheus console. In the left navigation pane, choose Alert Management > Notification Policies.

2. On the Notification Policies page, click Create Notification Policy.

3. At the top of the Create Notification Policy page, enter a name for the policy.

4. In the Matching Rule section, define the matching rules for alert events.

   Important

   A silence policy takes precedence over a notification policy. An alert event that matches a silence policy is silenced and not evaluated against any notification policy. To create a silence policy, see Silence policies.

   1. Select a data source.

      • Specific source: Filters alert events from a specified integration.

      • No preset source: Filters alert events from all integrations.

   2. Set the matching rule expressions. You can use custom tags or select from existing tags.

      Existing tags include:

      • Tags from the metrics in an alert rule expression. To learn how to create tags for a Managed Service for Prometheus alert rule, see Create a Prometheus alert rule.

      • The ARMS system provides the following default tags.

        Category	Tag	Description
        Common fields	alertname	Alert name.
        	clustername	Cluster name.
        	severity	Severity level: P1 P2 P3 P4 Default
        	namespace	namespace.
        	pod_name	Pod name.
        System preset fields	_aliyun_arms_integration_name	Integration name. The default integration name for alerts reported by ARMS is ARMS-DEFAULT.
        	_aliyun_arms_involvedObject_id	Alert object ID.
        	_aliyun_arms_involvedObject_name	Alert object name.
        	_aliyun_arms_region_id	Region ID.
        	_aliyun_arms_alert_rule_id	Alert rule ID.
        	_aliyun_arms_alert_type	Alert rule type: 101: Prometheus alert 5: Application Monitoring alert 4: Browser Monitoring alert
        	_arms_contact_group_v2_id	Contact group ID (v2) for alert notifications. This tag is automatically added by ARMS to the alert event tags. Its value corresponds to the v2 contact group identifier shown on the Alarm Management > Notification Objects > Contact Group page in the console. When a notification policy is automatically created through ACK integration, this tag is used to match the policy without any manual configuration. This tag differs from the v1 ContactGroupId returned by the API. It is visible in the commonLabels field of the webhook notification payload.

      Tag display behavior

      The tags shown on the alert event analysis page come from the metric labels carried by the triggered alert rule and from system preset fields. Different alert events may carry different tag fields because the alert rules involved are associated with different metrics and resource types. An event that does not carry a given field does not display that tag. As a result, some tags may appear for one event and not for another — this is expected behavior, not a system error.

      For example, an event carries the pod_name tag only when the alert involves a Pod resource. Alerts that do not involve a Pod do not display this tag.

      Note

      • To require an alert to match all conditions in a rule (AND logic), click Add Condition.

      • To require an alert to match any rule (OR logic), click Add Rule to create a new rule.

      • The total configuration size of all matching rules in a notification policy cannot exceed 64 KB. This limit accommodates approximately 100 rules, depending on their complexity. Exceeding this limit causes the configuration to fail. To avoid this, create a new notification policy for additional rules.

      Note

      When a notification policy contains matching rules based on cluster or object dimensions — for example, using the label _aliyun_arms_involvedObject_id to match a Kubernetes cluster ID — alert rules associated with the matched cluster or object are automatically linked to the notification policy. You do not need to configure a notification policy on each individual alert rule.

      This is especially useful for bulk scenarios, such as alert rules automatically created by Container Service for Kubernetes (ACK). You only need to configure label-based matching rules in the notification policy to automatically associate all relevant alert rules at once, without editing them one by one.

      Alert rules automatically created by an ACK cluster carry the system-generated tag _arms_contact_group_v2_id, whose value is a contact group ID. Notification policies use this tag to match rules and route alert notifications to the specified contact group. The tag value corresponds to the contact group ID shown on the Alarm Management > Notification Objects > Contact Group page in the ARMS console. This tag is generated automatically by the system and does not need to be added manually.

   3. Click Next.

5. In the Event Group section, configure how alert events are grouped, and then click Next.

   • Do not group: Each alert event is sent as a separate notification.

   • Set grouping fields: Groups alert events that have identical values for the specified fields into a single notification.

6. In the Notification Objects section, configure the following parameters.

   1. Click +Add Notification Recipient to select a notification recipient.

      Notification recipient types:

      • Contact: You must also select a notification method (phone call, text message, or email) for the selected contact.

      • Contact Group: You must also select a notification method (phone call, text message, or email) for the selected contact group.

      • On-call Schedule: You must also select a notification method (phone call, text message, or email) for the selected on-call schedule.

      • DingTalk/Lark/WeCom: Sends notifications to a DingTalk, Lark, or WeCom channel.

      • General Webhook: Sends notifications to a specified webhook URL.

   2. Select whether to send a recovery notification after an alert is resolved.

      Send recovery notification: When enabled, a recovery notification is sent after all events in an alert are resolved, and the alert is then automatically marked as Resolved.

   3. Set a notification template. For more information, see Configure notification and webhook templates.

   4. Define a notification period to send alerts only within the specified time window.

   5. Optional: Select a ticket system to push alerts to. For details about how to integrate a ticket system, see Integrations.

   6. Click Next.

7. In the Repeat/escalation/recovery policy section, configure policies for unresolved alerts. You can set up repeat notifications, apply an escalation policy, or require manual recovery. Then, click Next.

   • If you do not configure an escalation policy, the system sends only one notification for an unresolved alert.

   • Repeat notifications: Set a frequency. If an alert is not resolved, notifications are resent at the specified interval until the alert is resolved.

   • Escalation policy: Select a policy. If an alert is not resolved, the system sends notifications to additional recipients according to the selected escalation policy.

   • Manual recovery: If you enable this option, an alert does not automatically resolve even if no new alert events are triggered within the automatic resolution period defined in the alert integration. You must manually change the alert status.

8. In the Action Integration section, configure an action integration to run automatically.

   If you enable this option, you must select the action integrations to run when an alert is triggered and when it is resolved. The system will then run them automatically.

9. Click Save to create the policy.

Manage notification policies

After a notification policy is created, it is displayed on the Notification Policies page. On the Notification Policies page, you can perform the following operations:

• Edit a notification policy: Click the policy name or click Edit in the Actions column. After making your changes, click Save.

• Enable or disable a notification policy: In the Status column, toggle the switch.

• Delete a notification policy: Click Delete in the Actions column, and then click Confirm.

• Copy a notification policy: Click Copy in the Actions column to duplicate the policy.