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 no longer takes effect.

• The recipient cloud service specified in each notification rule must be unique in a scaling group. 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, make sure that the specified topic resides in the same region as your scaling group.

• If you set the Notification Method parameter to CloudMonitor, you do not need to pay 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 Configure 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 Manage event notification rules.

   • API operation: For detailed operations, see CreateNotificationConfiguration.

3. Trigger a scaling event.

   You can execute an event-triggered task, a scaling rule, or a health check task to trigger a scaling event. In this topic, a scaling rule is executed to trigger a scaling event. 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 event details

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

   {
       "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****",
       "scalingGroupTags": [
           {
               "key": "acs:rm:rg**",
               "value": "rg-acfmzx3vure****"
           }
       ],
       "startTime": "2022-03-31T09:16:04.000Z",
       "totalCapacity": 2
   }

   The preceding snippet includes the following fields:

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

   • description: the execution result of the scaling event.

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

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

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

   • requestId: the ID of the scaling request.

   • scalingActivityId: the ID of the scaling event.

   • scalingGroupTags: The tags of the scaling group that is associated with the scaling activity.

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

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

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

   If you want 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 (old).

   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 Event Successful Scale-in Event Start of Scale-out Event Start of Scale-in Event All the preceding events
   WARN	Scaling Request Rejected Expiration of Scheduled Task Partly Successful Scale-out Event Partly Successful Scale-in Event All the preceding events
   CRITICAL	Failed Scale-out Event Failed Scale-in Event All the preceding events

Enable the event notification feature based on a SMQ queue

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

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 Configure 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 SMQ queue.

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

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

   • API operation: For detailed operations, see CreateQueue.

   Note

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

3. Create an SMQ 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 Manage event notification rules.

   • API operation: For detailed operations, see CreateNotificationConfiguration.

4. Trigger a scaling event.

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

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

   For information about how to view messages in an SMQ queue, see Manage queues in the console or ReceiveMessage. In most cases, the message 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 event details in the JSON format to the specified SMQ queue. SMQ can automatically consume the pushed message. The following snippet provides an example of a successful scale-out event.

   {
       "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****",
           "scalingGroupTags": [
               {
                   "key": "acs:rm:rg**",
                   "value": "rg-acfmzx3vure****"
               }
           ],
           "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 snippet includes the following fields:

   • content: the scaling event details.

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

     • description: the execution result of the scaling event.

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

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

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

     • requestId: the ID of the scaling request.

     • scalingActivityId: the ID of the scaling event.

     • scalingGroupTags: The tags of the scaling group that is associated with the scaling activity.

     • startTime: the time at which the scaling event 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 successful, the event level is INFO. If the scaling request is rejected, the event level is WARN. If the event failed, 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 SMQ 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. The MNS topic provides more subscription types than the MNS queue, including MNS queues and HTTP.

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 Configure 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 SMQ topic.

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

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

   • API operation: For detailed operations, see CreateTopic.

   Note

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

3. Create a subscription for the SMQ topic.

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

   • SMQ 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 the topic 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, and Email Address.

4. Create an SMQ 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 Manage event notification rules.

   • API operation: For detailed operations, see CreateNotificationConfiguration.

5. Trigger a scaling event.

   You can execute an event-triggered task, a scaling rule, or a health check task to trigger a scaling event. 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 SMQ topic. Then, the SMQ topic pushes the message to its subscribers for individual consumption.