DocsICP FilingConsole
Documentation
Home Page Auto Scaling User Guide Message notifications Configure event notifications for a scaling group

Configure event notifications for a scaling group

Updated at:
Copy as MD
Product
My Favorites

Event notification is a monitoring mechanism that sends a message to a notification recipient that you specify—a CloudMonitor system event, an SMQ queue, or an SMQ topic—after a scaling activity occurs in a scaling group. Event notification helps you keep track of instance changes in the scaling group and monitor scaling group information in real time. This topic describes how to configure an event notification for each of the three notification methods.

Background

Event notification supports 11 notification types (scaling activity types) and three notification methods (notification recipients). For more information, see Overview of message notifications and Configure event notifications.

  • Notification types: When you create an event notification, you must specify the type of scaling activity that triggers the notification. The following table lists the supported notification types.

    Type (Auto Scaling console)

    Type (API)

    Successful scale-out

    AUTOSCALING:SCALE_OUT_SUCCESS

    Successful scale-in

    AUTOSCALING:SCALE_IN_SUCCESS

    Failed scale-out

    AUTOSCALING:SCALE_OUT_ERROR

    Failed scale-in

    AUTOSCALING:SCALE_IN_ERROR

    Auto Scaling rejects the scaling activity

    AUTOSCALING:SCALE_REJECT

    Started scale-out

    AUTOSCALING:SCALE_OUT_START

    Started scale-in

    AUTOSCALING:SCALE_IN_START

    Scheduled task expiring

    AUTOSCALING:SCHEDULE_TASK_EXPIRING

    Diagnosis of the scaling group

    SCALING_GROUP_DIAGNOSE

    Partly successful scale-out

    AUTOSCALING:SCALE_OUT_WARN

    Partly successful scale-in

    AUTOSCALING:SCALE_IN_WARN

  • Notification methods: When a scaling activity triggers an event notification, Auto Scaling reports the details of the scaling activity to the notification recipient that you configured. Auto Scaling can send the message to a CloudMonitor system event, an SMQ queue, or an SMQ topic, so that you can automate the management of your scaling groups. For more information about CloudMonitor system events or Simple Message Queue (formerly MNS), see CloudMonitor system event monitoring and What is Alibaba Cloud Simple Message Queue?.

    Note

    You can also set up message notifications, which Auto Scaling sends by using SMS messages, internal messages, and emails. However, after you receive a message notification, you must handle the results of the scaling activity, that is, the scale-out or scale-in results, manually. For more information, see Set up message notifications.

Usage notes

  • You can create up to six event notifications for each scaling group.

  • If an event notification is already configured for a scaling group, you cannot set up message notifications for that scaling group.

  • If a scaling group uses the new event notification feature, the alert trigger rules that the scaling group originally used no longer take effect. Event-triggered tasks are not affected.

  • You cannot use the same notification recipient more than once within a scaling group. For example, you can use the CloudMonitor system event of a scaling group as a notification recipient only once within that scaling group.

  • If you use the SMQ topic notification method, make sure that the SMQ topic and the scaling group reside in the same region.

  • Compared with the CloudMonitor system event method, the Simple Message Queue (formerly MNS) method incurs charges.

    For more information about billing, see SMQ billing details.

Using CloudMonitor system events

When a scaling activity of a configured notification type occurs in a scaling group, Auto Scaling reports the details of the scaling activity to CloudMonitor as a system event. When the system event triggers a system event alert rule that you configured, CloudMonitor sends an alert message to the contact group that is specified in the alert rule. You can manage the recipients of the scaling activity details by managing the contact group.

  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 by calling API operations.

  2. Create an event notification that uses a CloudMonitor system event.

    You can create an event notification by using the Auto Scaling console or by calling an API operation.

  3. Trigger a scaling activity.

    You can trigger a scaling activity by using an event-triggered task, by executing a scaling rule, or by using an instance health check. This example uses the execution of a scaling rule. For more information, see Execute a scaling rule.

  4. View the system event that is reported 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 main information:

    • The event name, the event level, and the status

    • The ID of the scaling group

    • The details of the scaling activity

    Auto Scaling reports the scaling activity details to CloudMonitor in JSON format. The following example shows the details of a successful scale-out activity in a scaling group:

    {
    "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 meanings of the fields in the scaling activity details in the example above are as follows:

    • cause: The cause of the scaling activity.

    • description: The execution result of the scaling activity.

    • endTime: The end time of the scaling activity.

    • expectNum: The number of instances that are expected to be added in this scaling activity. This field is returned only for successful scaling activities.

    • instanceIds: The IDs of the instances that are actually added in this scaling activity. This field is returned only for successful scaling activities.

    • requestId: The request ID of this scaling activity.

    • scalingActivityId: The ID of this scaling activity.

    • scalingGroupTags: All tags of the scaling group that corresponds to this scaling activity.

    • startTime: The start time of the scaling activity.

    • totalCapacity: The current number of instances in the scaling group.

  5. Create a system event alert rule.

    If you want CloudMonitor to further notify you of the event details by using SMS messages, emails, or DingTalk, you must create an alert rule for the corresponding system event in the CloudMonitor console. For more information, see Manage system event alert rules (legacy).

    Auto Scaling classifies the system events that it reports to CloudMonitor into three levels: INFO, WARN, and CRITICAL. Each level corresponds to different notification types, as described in the following table.

    System event level

    Notification type (scaling activity type)

    INFO

    • Successful scale-out

    • Successful scale-in

    • Started scale-out

    • Started scale-in

    • All events (a collection of the preceding events)

    WARN

    • Auto Scaling rejects the scaling activity

    • Scheduled task expiring

    • Partly successful scale-out

    • Partly successful scale-in

    • All events (a collection of the preceding events)

    CRITICAL

    • Failed scale-out

    • Failed scale-in

    • All events (a collection of the preceding events)

Using an SMQ queue

When a scaling activity of a configured notification type occurs in a scaling group, Auto Scaling pushes the details of the scaling activity to the corresponding SMQ queue. As a best practice, use long polling to consume the messages in the SMQ queue and obtain the scaling activity details. If you need to consume a message in the SMQ queue only once, delete the message from the queue after you consume it. For more information about long polling, 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 by calling API operations.

  2. Create an SMQ queue.

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

    Note

    The SMQ queue service is not yet available in some regions. Scaling groups in those regions cannot use an SMQ queue as the notification recipient. For the regions that are supported, see the SMQ console.

  3. Create an Auto Scaling event notification that uses an SMQ queue.

    You can create an event notification by using the Auto Scaling console or by calling an API operation.

  4. Trigger a scaling activity.

    You can trigger a scaling activity by using an event-triggered task, by executing a scaling rule, or by using an instance health check. This example uses the execution of a scaling rule. For more information, see Execute a scaling rule.

  5. View the messages that the SMQ queue receives.

    For more information about how to view the messages that an SMQ queue receives, see Receive messages or ReceiveMessage. The details of a received message include the following main information:

    • Basic information: the message ID, the message handle, the consumption count, the consumption time, and the message creation time.

    • Message content: the original message content, the Base64-decoded message content, and the MD5 value of the message.

    Auto Scaling pushes the scaling activity details to the SMQ queue in JSON format, and SMQ can consume the message automatically. The following example shows the details of a successful scale-out activity in a scaling group:

    {
    "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 meanings of the fields in the scaling activity details in the example above are as follows:

    • The content parameter contains the details of this scaling activity, including the following fields:

      • cause: The cause of the scaling activity.

      • description: The execution result of the scaling activity.

      • endTime: The end time of the scaling activity.

      • expectNum: The number of instances that are expected to be added in this scaling activity. This field is returned only for successful scaling activities.

      • instanceIds: The IDs of the instances that are actually added in this scaling activity. This field is returned only for successful scaling activities.

      • requestId: The request ID of this scaling activity.

      • scalingActivityId: The ID of this scaling activity.

      • scalingGroupTags: All tags of the scaling group that corresponds to this scaling activity.

      • startTime: The start time of the scaling activity.

      • totalCapacity: The current number of instances in the scaling group.

    • event: The type of the scaling activity that corresponds to this event notification. The value is one of the scaling activity types that event notification supports.

    • eventLevel: The level of the event. Three levels are available: INFO, WARN, and CRITICAL, which correspond to a successful scaling activity, a rejected scaling activity, and a failed scaling activity, respectively.

    • eventStatus: The running status of the event notification.

    • product: The name of the cloud service, which is Auto Scaling.

    • resourceArn: The unique identifier of the scaling group, which includes the region, the user ID, and the scaling group ID.

    • regionId: The region ID of the scaling group.

    • userId: The ID of the user to which the scaling group belongs.

Using an SMQ topic

When a scaling activity of a configured notification type occurs in a scaling group, Auto Scaling pushes the details of the scaling activity to the SMQ topic. An SMQ topic supports more message consumption methods than an SMQ queue: in addition to the methods that an SMQ queue supports, an SMQ topic supports methods such as HTTP for consuming event notifications.

  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 by calling API operations.

  2. Create an SMQ topic.

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

    Note

    The SMQ topic service is not yet available in some regions. Scaling groups in those regions cannot use an SMQ topic as the notification recipient. For the regions that are supported, see the SMQ console.

  3. Create a subscription for the SMQ topic.

    Unlike a message in an SMQ queue, a message that an SMQ topic receives cannot be consumed directly. You must first create a subscription for the SMQ topic. You can create a subscription by using the SMQ console or by calling an API operation.

    After you create the subscription, the SMQ topic pushes each message that it receives to the corresponding subscriber in real time. SMQ topics support the following subscription methods: HTTP, Queue, Alibaba Cloud SMS, and Mailbox.

  4. Create an Auto Scaling event notification that uses an SMQ topic.

    You can create an event notification by using the Auto Scaling console or by calling an API operation.

  5. Trigger a scaling activity.

    You can trigger a scaling activity by using an event-triggered task, by executing a scaling rule, or by using an instance health check. This example uses the execution of a scaling rule. For more information, see Execute a scaling rule.

    When a scaling group triggers one of the scaling activities that are configured in the event notification, Auto Scaling pushes the details of the scaling activity to the SMQ topic. After the topic receives the message, the topic pushes the message to the subscriber that is configured for the SMQ topic, and the subscriber consumes the message.

Previous：Configure event notificationsNext：Rolling update