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
API 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.
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 Simple Message Queue (formerly MNS) (SMQ) and then use SMQ to subscribe to the events.
Prerequisites
EventBridge is activated and the required permissions are granted to a Resource Access Management (RAM) user. For more information, see Activate EventBridge and grant permissions to a RAM user.
A DingTalk chatbot is created. The webhook URL and secret token of the DingTalk chatbot are recorded.
A function and a service are created in Function Compute. For more information, see Manage services and Manage functions.
SMQ is activated and an SMQ queue is created. For more information, see Activate SMQ and authorize RAM users to access SMQ and Get started with queue-based messaging.
Step 1: Select the system 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 system event bus in real time by using various channels. You can query and subscribe to the events on the system event bus.
Log on to the EventBridge console. In the left-side navigation pane, click Event Buses.
In the top navigation bar, select a region.
On the Event Buses page, find the system event bus and click its name default.
Step 2: Create a subscription rule for ECS events
In the left-side navigation pane of the details page of the system event bus, click Event Rules and then click Create Rule.
In the Create Rule wizard, perform the following steps:
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.
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" } }
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 SMQ
You can use SMQ 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 SMQ, see Billing.
Service Type: Select SMQ.
Queue: Select the SMQ 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 the data is delivered to the destination SMQ queue.
If you set the Service Type parameter to SMQ, you can download the NetworkInterfaceDemo.zip file to listen to SMQ 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:
Variables: 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 Variables 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.
Log on to the ECS console.
In the left-side navigation pane, choose .
In the top navigation bar, select the region where the ECS instance that you want to manage resides.
Find the ECS instance that you want to manage and choose
in the Actions column to change the status of the instance.
Step 4: View the delivery result
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.
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.
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.
Log on to the CloudMonitor console.
In the left-side navigation pane, choose
.In the left-side navigation tree of the Cloud Service Monitoring page, click Middleware. In the Middleware section of the page that appears, move the pointer over EventBridge and then click EventBus.
In the upper-left corner of the EventBus page, select the region. Then, click Monitoring Charts in the Actions column of the default event bus to view the monitoring details.
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 Configure an alert rule.
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, SMQ, 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.