How to Design and Use Cloud Monitoring Event Subscriptions on Alibaba Cloud

Background

In today's fast‑moving digital era, IT systems and applications are critical to business operations. Monitoring events allow IT teams to detect, analyze, and respond to issues such as server crashes, network interruptions, or application errors, which can affect continuity, customer satisfaction, and revenue.

What are System Events?

In Alibaba Cloud, system events differ from metric alarms; they carry complete context and describe service status changes. Typical examples include:

Key status events such as ECS restart, auto‑scaling failure, IOT QPS limit.

Recording and auditing events, e.g., OSS delivery failure.

Continuity issues like ongoing DDoS blackhole.

Important security alerts, e.g., abnormal network connection.

Most cloud services have already integrated with CloudMonitor; see the documentation for details.

Design Intent of Cloud‑Monitor Event Subscription

Before the subscription feature, alerts were set via alarm rules, which were inflexible, lacked blacklist support, and had rigid notification formats.

Based on user requirements, the new subscription provides:

Flexible subscription configuration supporting system or threshold events, with filtering by product, event level, name, resource, content, and whitelist/blacklist.

Aggregation and noise‑reduction by merging alerts at product, event, or resource level, and conditional deduplication (e.g., only notify after a certain number of events within a time window).

Direct push of effective alerts to email, phone, SMS, DingTalk, Enterprise WeChat, etc.

Customizable notification templates for personalized formats.

Custom notification methods allowing routing to MNS, SLS, Function Compute, Webhook, and others.

Typical Cloud‑Monitor Scenarios

Scenario 1: Multiple Operations Teams

Two independent teams manage ECS/SLB and RDS/Redis respectively. They need to monitor their own resources, provide backup phone alerts, and exclude pre‑release or test instances.

Steps:

Enter the Event Center and create a subscription policy.

Configure subscription scope (e.g., all CRITICAL ECS and RDS events, excluding test resources).

Set aggregation by product and require five consecutive events within five minutes before notifying.

Configure notification targets (email, phone, etc.) and optional backup phone groups.

Customize notification templates and push formats.

Optionally add custom channels such as Webhook.

Scenario 2: Application Group for Flexible Subscriptions

Application groups aggregate related cloud resources (ECS, RDS, SLB). By enabling system‑event subscription on a group, users receive notifications for CRITICAL and WARNING events of the grouped resources.

Procedure:

Navigate to Cloud Resource Monitoring → Application Groups and select a group.

Set the contact group for the application group.

Enable system‑event subscription.

Optionally add push channels (MNS, SLS, Function Compute, Webhook) via the notification details.

Conclusion

The two scenarios illustrate how users can extend the subscription capability to meet diverse monitoring needs, leveraging templates and custom notifications to achieve flexible, reliable cloud‑native monitoring.