Auto Scaling:Enable the event notification feature

Usage notes

• In each scaling group, you can create up to six advanced notification rules.

• If you create an advanced notification rule for a scaling group, you cannot create a regular notification rule for the scaling group.

• If you create a new advanced notification rule for a scaling group, the trigger condition of the existing advanced notification rule does not take effect anymore.

• In a scaling group, the recipient cloud service specified in each notification rule must be unique. For example, you can set the Notification Method parameter to CloudMonitor only once in a scaling group.

• If you set the Notification Method parameter to MNS Topic or MNS Queue, you must make sure that the specified MNS topic or MNS queue resides in the same region as your scaling group.

• If you set the Notification Method parameter to CloudMonitor, you do not need to pay any fees. If you set the Notification Method parameter to MNS Topic or MNS Queue, you need to pay a specific amount of fees.

Enable the event notification feature based on CloudMonitor

When the specified type of scaling event occurs in a scaling group, Auto Scaling reports the scaling event details as a system event to CloudMonitor. CloudMonitor triggers the preconfigured alert rule and then sends alert messages to the contacts based on the alert rule. You can manage the recipient parties of scaling event details by managing your contact group specified in the alert rule.

1. Create a scaling group and a scaling configuration.

   You can create a scaling group and a scaling configuration by using the Auto Scaling console or calling API operations.

   • Auto Scaling console: For detailed operations, see Manage scaling groups, Create a scaling configuration of the ECS type, and Create a scaling configuration of the Elastic Container Instance type.

   • API operations: For detailed operations, see CreateScalingGroup and CreateScalingConfiguration.

2. Create a CloudMonitor-based notification rule.

   You can create a CloudMonitor-based notification rule in the Auto Scaling console or by calling an API operation.

   • Auto Scaling console: For detailed operations, see Create an advanced notification rule.

   • API operation: For detailed operations, see CreateNotificationConfiguration.

3. Trigger a scaling activity.

   You can trigger a scaling activity by executing an event-triggered task, a scaling rule, or a health check task. In this topic, a scaling rule is executed to trigger a scaling activity. For more information about how to execute a scaling rule, see Execute a scaling rule.

4. View the result after Auto Scaling reports the scaling event details as a system event to CloudMonitor.

   For more information about how to view system events, see View system events. A system event that is reported to CloudMonitor includes the following information:

   • Event name, event level, and status description

   • Scaling group ID

   • Scaling activity details

   Auto Scaling reports scaling event details in the JSON format to CloudMonitor. The following code snippet provides an example of a successful scale-out.

   {
       "cause":"A user changed the Desired Capacity, changing the Total Capacity from \"1\" to \"2\".",
       "description":"\"1\" ECS instances are added",
       "endTime":"2022-03-31T09:16:30.000Z",
       "expectNum":1,
       "instanceIds":["i-bp1dn0ktfed9o0ys****"],
       "requestId":"INNER_WP2BReMYw3Fdic7dmbp****",
       "scalingActivityId":"asa-bp1eig7303qrgcxu****",
       "startTime":"2022-03-31T09:16:04.000Z",
       "totalCapacity":2
   }

   The preceding code snippet includes the following fields:

   • cause: the reason why the scaling activity is triggered.

   • description: the execution result of the scaling activity.

   • endTime: the time at which the scaling activity ends.

   • expectNum: the number of instances that are expected to be added during the scale-out. This field is available only when the scale-out is successful.

   • instanceIds: the IDs of the instances that are successfully added during the scale-out. This field is available only when the scale-out is successful.

   • requestId: the ID of the scaling request.

   • scalingActivityId: the ID of the scaling activity.

   • startTime: the time at which the scaling activity starts.

   • totalCapacity: the total number of instances in the scaling group.

5. Create an alert rule for the reported system event.

   If you want to use CloudMonitor to notify you of the event details by text message, email, or DingTalk, you must create an alert rule for the system event in the CloudMonitor console. For more information, see Manage system event-triggered alert rules.

   System events that are reported by Auto Scaling to CloudMonitor are classified into three levels: INFO, WARN, and CRITICAL. The following table lists the system events that correspond to different levels.

   System event level	Event type
   INFO	Successful Scale-out Successful Scale-in Scale-out Started Scale-in Started All the preceding events
   WARN	Scaling Request Rejected Scheduled Task Expired Partly Successful Scale-out Partly Successful Scale-in All the preceding events
   CRITICAL	Scale-out Failed Scale-in Failed All the preceding events

Enable the event notification feature based on an MNS queue

When the specified type of scaling event occurs, Auto Scaling pushes the scaling event details as a message to the specified MNS queue. We recommend that you use the long polling mechanism provided by MNS to consume the message. If you consume a message in an MNS queue only once, you can delete the MNS queue after you consume the message. For more information about the long polling mechanism, see Long polling mechanism.

1. Create a scaling group and a scaling configuration.

   You can create a scaling group and a scaling configuration by using the Auto Scaling console or calling API operations.

   • Auto Scaling console: For detailed operations, see Manage scaling groups, Create a scaling configuration of the ECS type, and Create a scaling configuration of the Elastic Container Instance type.

   • API operations: For detailed operations, see CreateScalingGroup and CreateScalingConfiguration.

2. Create an MNS queue.

   You can create an MNS queue by using the MNS console or calling an API operation.

   • MNS console: For detailed operations, see Create a queue.

   • API operation: For detailed operations, see CreateQueue.

   Note

   The MNS queue service is unavailable in specific regions. In these regions, you cannot specify an MNS queue as the recipient cloud service. The regions that are displayed in the MNS console shall prevail.

3. Create an MNS queue-based notification rule.

   You can create a CloudMonitor-based notification rule in the Auto Scaling console or by calling an API operation.

   • Auto Scaling console: For detailed operations, see Create an advanced notification rule.

   • API operation: For detailed operations, see CreateNotificationConfiguration.

4. Trigger a scaling activity.

   You can trigger a scaling activity by executing an event-triggered task, a scaling rule, or a health check task. In this topic, a scaling rule is executed to trigger a scaling activity. For more information about how to execute a scaling rule, see Execute a scaling rule.

5. View the message that is pushed to the MNS queue.

   For information about how to view the messages in an MNS queue, see Receive a message or ReceiveMessage. The message typically contains the following information:

   • Basic information, which includes the message ID, message handle, number of times the message is consumed, time when the message is consumed, and time when the message is created.

   • Message content, which includes the original content, Base64-decoded content, and MD5-hashed content.

   Auto Scaling pushes scaling activity details in the JSON format to the specified MNS queue. MNS can directly consume the pushed message. The following code snippet provides an example of a successful scale-out.

   {
       "content":{
       "cause":"A user changed the Desired Capacity, changing the Total Capacity from \"0\" to \"1\".",
       "description":"\"1\" ECS instances are added",
       "endTime":"2022-04-01T03:59:55.000Z",
       "expectNum":1,
       "instanceIds":["i-bp1imzcyvwrz2kzx****"],
       "requestId":"INNER_cpaMr4xcLVSdq0CFMdz****",
       "scalingActivityId":"asa-bp1ekb3kyj2qx1gx****",
       "startTime":"2022-04-01T03:59:29.000Z",
       "totalCapacity":1
       },
       "event":"AUTOSCALING:SCALE_OUT_SUCCESS",
       "eventLevel":"INFO",
       "eventStatus":"normal",
       "product":"ESS",
       "regionId":"cn-hangzhou",
       "resourceArn":"acs:ess:cn-hangzhou:160998252992****:scalingGroup/asg-bp10uuhy2wbb2tip****",
       "userId":"160998252992****"
   }

   The preceding code snippet includes the following fields:

   • content: the scaling activity details:

     • cause: the reason why the scaling activity is triggered.

     • description: the execution result of the scaling activity.

     • endTime: the time at which the scaling activity ends.

     • expectNum: the number of instances that are expected to be added during the scale-out. This field is available only when the scale-out is successful.

     • instanceIds: the IDs of the instances that are successfully added during the scale-out. This field is available only when the scale-out is successful.

     • requestId: the ID of the scaling request.

     • scalingActivityId: the ID of the scaling activity.

     • startTime: the time at which the scaling activity starts.

     • totalCapacity: the total number of instances in the scaling group.

   • event: the type of the scaling event.

   • eventLevel: the event level, which can be INFO, WARN, or CRITICAL. If the event is a successful scaling activity, the event level is INFO. If the event is a rejected scaling request, the event level is WARN. If the event is a failed scaling activity, the event level is CRITICAL.

   • eventStatus: the status of the event notification rule.

   • product: the name of the cloud service. In this case, the name is Auto Scaling.

   • resourceArn: the Alibaba Cloud Resource Name (ARN) of the scaling group, which includes the region of the scaling group, the ID of the Alibaba Cloud account, and the scaling group ID.

   • regionId: the region ID of the scaling group.

   • userId: the ID of the Alibaba Cloud account to which the scaling group belongs.

Enable the event notification feature based on an MNS topic

When the specified type of scaling event occurs in a scaling group, Auto Scaling pushes the scaling event details as a message to the specified MNS topic. Compared with the MNS queue, the MNS topic provides more subscription types, including MNS queues, HTTP, and Alibaba Cloud Mobile Push.

1. Create a scaling group and a scaling configuration.

   You can create a scaling group and a scaling configuration by using the Auto Scaling console or calling API operations.

   • Auto Scaling console: For detailed operations, see Manage scaling groups, Create a scaling configuration of the ECS type, and Create a scaling configuration of the Elastic Container Instance type.

   • API operations: For detailed operations, see CreateScalingGroup and CreateScalingConfiguration.

2. Create an MNS topic.

   You can create an MNS topic in the MNS console or by calling an API operation.

   • MNS console: For detailed operations, see Create a topic.

   • API operation: For detailed operations, see CreateTopic.

   Note

   The MNS topic service is unavailable in specific regions. In these regions, you cannot specify an MNS topic as the recipient cloud service in a notification rule. The regions that are displayed in the MNS console shall prevail.

3. Create a subscription for the MNS topic.

   Before you consume the message pushed to your MNS topic, you must create a subscription. Different from the MNS queue service, the MNS topic service does not support the direct consumption of messages. You must create a subscription in the MNS console or by calling an API operation.

   • MNS console: For detailed operations, see Create a subscription.

   • API operation: For detailed operations, see Subscribe.

   After you create the subscription, the MNS topic that you use immediately pushes the message to its subscribers after it receives the message about the scaling event details from Auto Scaling. The MNS topic service supports the following subscription types: HTTP, Queue, Alibaba Cloud SMS, Email Address, and Alibaba Cloud Mobile Push.

4. Create an MNS topic-based notification rule.

   You can create a CloudMonitor-based notification rule in the Auto Scaling console or by calling an API operation.

   • Auto Scaling console: For detailed operations, see Create an advanced notification rule.

   • API operation: For detailed operations, see CreateNotificationConfiguration.

5. Trigger a scaling activity.

   You can trigger a scaling activity by executing an event-triggered task, a scaling rule, or a health check task. In this example, a scaling rule is executed to trigger a scaling activity. For more information about how to execute a scaling rule, see Execute a scaling rule.

   When the specified type of scaling event occurs in the scaling group, Auto Scaling pushes the scaling event details to the specified MNS topic. The MNS topic then pushes the message to its subscribers for individual consumption.