Application Real-Time Monitoring Service:Notification policies

Create a notification policy

1. Log on to the ARMS console. In the left-side 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/Escalate/Recover Policy section, configure whether to repeat notifications or use an escalation policy for an alert, and then click Next.

   • Repeat notifications for an alert: When enabled, notifications for unresolved alerts are resent at the specified frequency until the alert is resolved.

   • Escalation policy:

     If you select No escalation policy, the notification is sent only once for an unresolved alert.

     If you select Use escalation policy, the notification is sent to other recipients according to the escalation policy.

   • Manual recovery: When enabled, alerts will not be automatically resolved, even if no new events are triggered during the integration's automatic recovery period. You must resolve these alerts manually.

8. In the Action Integration section, configure automated actions that run when an alert is triggered or resolved. For more information, see Execute an alert plan by using an ARMS action integration.

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.

FAQ

Q: How do I configure different notification methods for different alert severities within a single notification policy?

A: You can add multiple Actions within the same notification policy to implement differentiated notifications. For each action, configure its matching conditions (for example, P1 severity or P2 severity) and select the corresponding notification channel (for example, phone call or DingTalk group). This approach eliminates the need to create a separate notification policy for each severity level.

Q: Why does the actual notification interval differ from the configured repeat notification interval?

A: The actual notification interval is affected by multiple overlapping factors:

• Prometheus alert check cycle: By default, Prometheus checks alerts every 1 minute.

• "Check after data is complete" mechanism: This mechanism is enabled by default. It adds additional processing time to ensure alert data is fully available before the system evaluates new events.

• Event aggregation and system processing delay: Additional delay occurs during event aggregation and downstream processing.

Due to these cumulative effects, the actual interval may be longer than the configured value. For example, a configured interval of 1 minute may result in an effective interval of 3 minutes.

In addition, recovery notifications are recalculated based on the timestamp of the last alert event. If alerts continue to trigger, recovery notifications will be delayed accordingly.

Q: Can the Alibaba Cloud user ID shown at the end of ARMS alert SMS messages be removed?

A: No. The text "This message was configured in ARMS by Alibaba Cloud user: xxxxxx" is a fixed system format and cannot be removed through configuration.