All Products
Search
Document Center

Elastic Compute Service:Use EventBridge to quickly subscribe to ECS events

Last Updated:Feb 19, 2024

This topic describes how to use EventBridge to subscribe to Elastic Compute Service (ECS) events and then deliver the events to downstream services.

Background information

EventBridge is a platform that is used to manage events in Alibaba Cloud in a centralized manner. EventBridge uses the standard CloudEvents 1.0 specification to connect cloud services and applications. You can use EventBridge to manage events that are generated in cloud services, Software as a Service (SaaS) services, and business applications. EventBridge provides a data reliability of 99.99999999% and a service availability of 99.95%. This ensures the quality of events from upstream cloud services, user experience in event subscription, and the reliability of data delivery.

Compared with the DescribeInstanceHistoryEvents operation provided by ECS, the event subscription feature provided by EventBridge has the following advantages:

  • Higher timeliness: When an event of a specific type is detected, a specific operation can be triggered within milliseconds.

  • Lower costs: Periodic polling is not required to check whether events are generated. This prevents unnecessary costs.

订阅ECS.png

Common scenarios

  • Subscribe to ECS events of a specific type and use the events to trigger the sending of notifications from DingTalk, Short Message Service, and Alibaba Mail.

  • Push ECS events of a specific type to downstream HTTP or HTTPS services over the Internet or in a virtual private cloud (VPC).

  • Aggregate ECS events that are generated in multiple Alibaba Cloud accounts.

  • When an ECS event of a specific type occurs, use Function Compute to trigger a specific operation.

  • When the latency of ECS events is high and the number of ECS events is large, deliver the events to Message Service (MNS) and then use MNS to subscribe to the events.

Prerequisites

Step 1: Select the default event bus

By default, EventBridge creates a system event bus whose name is default. Events that are generated in Alibaba Cloud services are delivered to the default event bus in real time by using various channels. You can query and subscribe to events in the default event bus.

  1. Log on to the EventBridge console. In the left-side navigation pane, click Event Buses.

  2. In the top navigation bar, select a region.

  3. On the Event Buses page, find the default event bus and click the name of the event bus.

Step 2: Create a subscription rule for ECS events

  1. In the left-side navigation pane of the details page of the default event bus, click Event Rules and then click Create Rule.

  2. In the Create Rule panel, perform the following steps:

    1. In the Configure Basic Info step, enter a rule name in the Name field and a rule description in the Description field. Then, click Next Step.

    2. In the Configure Event Pattern step, configure the parameters and click Next Step. The following items describe the parameters:

      • Select Alibaba Cloud Service Event Sources for the Event Source Type parameter.

      • Select acs.ecs Elastic Compute Service (ECS) from the Event Source drop-down list.

      • Select the type of events to which you want to subscribe from the Event Type drop-down list. You can select multiple types of events.

      • In the Event Pattern Debugging code editor, you can view the sample code of the events to which you want to subscribe. For example, if you select ecs:Instance:StateChange Instance Status Changes Within Lifecycle from the Event Type drop-down list, the following sample code is displayed in the Event Pattern Debugging code editor:

        {
          "id": "45ef4dewdwe1-7c35-447a-bd93-fab****",
          "source": "acs.ecs",
          "specversion": "1.0",
          "subject": "acs.ecs:cn-hangzhou:123456789098****:215672",
          "time": "2020-11-19T21:04:41Z",
          "type": "ecs:Instance:StateChange",
          "aliyunaccountid": "123456789098****",
          "aliyunpublishtime": "2020-11-19T21:04:42Z",
          "aliyuneventbusname": "default",
          "aliyunregionid": "cn-hangzhou",
          "aliyunpublishaddr": "172.25.XX.XX",
          "data": {
            "instanceName": "iZ0jl0kyquo46h****",
            "instanceType": "ecs.c6.large",
            "privateIpAddress": "172.21.XX.XX",
            "publicIpAddress": "8.37.XX.XX",
            "resourceId": "i-0jl0kyquo46****",
            "resourceType": "ALIYUN::ECS::Instance",
            "spotStrategy": "SpotWithPriceLimit",
            "state": "Running"
          }
        }
    3. In the Configure Targets step, select the service to which you want to deliver events and specify the scenario in which events are pushed.

      Scenario 1: Push ECS events to MNS

      You can use MNS to subscribe to events in scenarios in which the latency of events is high and the number of events is large. For information about the billing of MNS, see Pricing.

      • Service Type: Select Message Service.

      • Queue: Select the queue that you created.

      • Message Body: Select Complete Event.

      • Enable Base64 Decoding: Select Yes. After you enable Base64 encoding, your data is encoded in the Base64 format before it is sent to the destination MNS queue.

      If you set the Service Type parameter to Message Service, you can download the NetworkInterfaceDemo.zip file to listen to MNS messages and obtain events.

      Scenario 2: Push ECS events to DingTalk

      • Service Type: Select DingTalk.

      • Address: Enter the webhook URL of the DingTalk chatbot.

      • Secret Key: Enter the key of the DingTalk chatbot.

      • Pushed Content: You can specify a custom template and then specify the ECS event parameters that you want to push to the DingTalk chatbot in the template. For example, you can configure the instanceName and state parameters and push the parameters to the DingTalk chatbot. Sample code:

        • Parameters: Use JSONPath to obtain the field information about the ECS event parameters that you want to push and specify the variable names.

          {
            "instanceName":"$.data.instanceName",
            "state":"$.data.state"
          }
        • Template: Define a template in the format that is required by the DingTalk chatbot and introduce the variables that are defined in the Parameters code editor to the template.

          {
            "msgtype": "text",
            "text": {
                "content": "${instanceName} state is ${state}" 
            } 
          }

      Scenario 3: Push ECS events to downstream HTTP or HTTPS services

      • Service Type: Select HTTP or HTTPS.

      • URL: Specify the URL that you want to use to receive events.

      • Body: Specify the content of the events that you want to receive. EventBridge allows you to transform the events into the required format and then push the events to the destination HTTP service. Valid values: Complete Event, Partial Event, Fixed Value, and Template. For more information, see Event transformation.

      • Network Type:

        • Internet: Access the destination URL over the Internet.

        • VPC: If Internet access is not enabled for the destination URL, you can select this value. If you select this value, you must configure the VPC, vSwitch, and Security Group parameters.

      Scenario 4: Push ECS events of a specific type to trigger an operation

      If you want to trigger a specific operation when an ECS event of a specific type occurs, you can select Function Compute as the destination service. This way, you can push ECS events of the specified type to a Function Compute function and then specify the operation that you want to trigger in the code of the function.

      • Service Type: Select Function Compute.

      • Service: Select the name of the service that you created in Function Compute.

      • Function: Select the name of the function that you created in Function Compute.

      • Event: Specify the content of the events that you want to receive. EventBridge allows you to transform events into the required format and then push the events to Function Compute. Valid values: Complete Event, Partial Event, Fixed Value, and Template. For more information, see Event transformation.

      • Invocation Mode:

        • Synchronous: The request is considered successful only if the event is received by Function Compute and processed by the function.

        • Asynchronous: The request is considered successful after the event is received by Function Compute.

        For more information, see Route events to Function Compute.

      Scenario 5: Aggregate ECS events that are generated in multiple Alibaba Cloud accounts

      EventBridge allows you to aggregate ECS events that are generated in different Alibaba Cloud accounts and regions to an event bus that is created by using one Alibaba Cloud account in a specific region. In this case, you must select EventBridge as the destination service.

      • Destination Type:

        • Same-account Event Bus: Deliver events to another event bus that is created by using the same Alibaba Cloud account.

        • Cross-account Event Bus: Deliver events to an event bus that is created by using another Alibaba Cloud account. If you select Cross-account Event Bus, you must grant the required permissions to a RAM user. For more information, see Route events to EventBridge.

      • Region: You can deliver events that are created in a region in the Chinese mainland only to another region in the Chinese mainland, and events that are created in a region outside the Chinese mainland only to another region outside the Chinese mainland.

      • Event Bus: Select the name of the event bus to which you want to deliver events.

      • Event: Use the default value Complete Event. You cannot change the value of this parameter.

      In the Retry Policy and Dead-letter Queue section of the Configure Targets step, you can specify a retry policy and dead-letter queue based on your business requirements. For more information, see Retry policies and dead-letter queues.

      For information about other scenarios in which EventBridge is used to subscribe to ECS events, see Target service types.

Step 3: Trigger an event

In this example, an ECS event of the ecs:Instance:StateChange Instance Status Changes Within Lifecycle type is triggered. To trigger this type of event, you must change the status of an ECS instance.

  1. Log on to the ECS console.

  2. In the left-side navigation pane, choose Instances & Images > Instances.

  3. In the top navigation bar, select the region where the ECS instance that you want to manage resides.

  4. Find the ECS instance that you want to manage and choose image.png > Instance Status in the Actions column to change the status of the instance.

Step 4: View the delivery result

  1. Query whether an ECS event of the specified type is generated.

    EventBridge allows you to query ECS events by time range, event type, subscription rule name, and event ID. For more information, see Query events by event ID.

  2. Query the delivery result of the ECS event.

    You can click Event Trace in the Actions column of the event that you queried in the preceding step to view the delivery trace. The delivery trace includes the event destination, delivery status, number of times the event was delivered, and the time when the event was delivered.image.png

Event monitoring and alerting

You can view the number of API calls, delivery success rate, and delivery latency of the ECS events to which you subscribed on the dashboard of EventBridge. You can configure alert rules based on your business requirements.

  1. Log on to the CloudMonitor console.

  2. In the left-side navigation pane, choose Cloud Service Monitoring > Cloud Service Monitoring.

  3. On the Cloud Service Monitoring page, choose Others > EventBus.

  4. In the upper part of the page that appears, select a region and click Monitoring Charts in the Actions column of the default bus.image.png

On the page that appears, you can configure alert rules for EventBridge resources. When an alert is triggered based on the configured alert rules, CloudMonitor sends an alert notification to you. For more information, see the "Configure an alert rule" section of the Cloud service monitoring topic.

Retry policies and dead-letter queues

After an event is written to an event bus, EventBridge ensures that the event is pushed to the downstream service at least once. If the downstream service cannot receive the event as expected due to exceptions such as server failures, service unavailability, and network jitters, EventBridge allows you to configure a retry policy, fault tolerance policy, and dead-letter queue to handle the exceptions. You can configure a retry policy and dead-letter queue for the ECS events to which you subscribe in Step 2: Create a subscription rule for ECS events to ensure that the events are delivered as expected.

  • Retry policy

    If the downstream service cannot receive events as expected, exceptions occur in the events that are pushed from EventBridge. In this case, you can configure a retry policy for the events in the EventBridge console to maximize the success rate of event delivery to the downstream service.

    • Backoff Retry: A failed event can be retried up to three times. The interval between two consecutive retries is a random value between 10 and 20 seconds.

    • Exponential Decay Retry: A failed event can be retried 176 times at incremental intervals in the range of 1 to 512 seconds. The retries can last for up to one day. The specific intervals are 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds, 32 seconds, 64 seconds, 128 seconds, 256 seconds, and 512 seconds. The value 512 seconds is used for 167 retries.

  • Dead-letter queue

    If an event still fails to be pushed after the specified maximum number of retries is reached, EventBridge automatically discards the event. If you want to retain the event, you can specify a dead-letter queue and send the event to the queue. EventBridge allows you to use queues in ApsaraMQ for RocketMQ, Message Service, and ApsaraMQ for Kafka, and event buses in EventBridge as dead-letter queues.

  • Fault tolerance policy

    If your business requires events to be pushed in sequence, when an event fails to be pushed, you must suspend the push task until the failed event is pushed. In this case, you must prohibit fault tolerance. If your business does not require events to be pushed in sequence, we recommend that you allow fault tolerance to ensure the maximum push concurrency.

    • Fault Tolerance Allowed: Fault tolerance is allowed. If an exception occurs in an event, event processing is not blocked. If the event fails to be pushed after the maximum number of retries that is specified by the retry policy is reached, the event is delivered to the dead-letter queue or discarded.

    • Fault Tolerance Prohibited: Fault tolerance is not allowed. If an exception occurs in an event and the event fails to be pushed after the maximum number of retries that is specified by the retry policy is reached, the event processing is blocked.