本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 自定义事件总线的可观察性：指标、日志和 CloudTrail
三个消息来源告诉你公共汽车及其订阅者在做什么。`AWS/EventsV2`命名空间中的亚马逊 CloudWatch 指标为每个订阅者启用；在交付失败时发出警报，`EventsDelivered`用指标数学开启或`EventDeliveryAttempts`减去警报。`OnFailureDestinationDelivered` `EventsDropped`订阅者日志将每次交付尝试记录为 JSON 记录；`LogConfiguration.Level`在您设置订阅者之前，它们会一直处于关闭状态。 Amazon CloudTrail 记录创建和更改总线、订阅者和事件源的 API 调用。
## 指标
订阅者指标有两个维度 `EventBus``Subscriber`，每个维度都包含资源 ARN。当订阅者属于与总线不同的账户时， EventBridge 还会发出带有`EventBus`和的指标，`SubscriberAccount`这样总线所有者就可以看到每个账户的消耗量。下表列出了 指标。
| 指标 | 单位 | 含义 |
| --- | --- | --- |
| FilterEvaluated | 计数 | 根据订阅者的过滤器评估的事件 |
| FilterMatched | 计数 | 符合所有筛选条件的事件 |
| EventDeliveryAttempts | 计数 | 交付尝试次数，按事件计算。减去EventsDelivered以计算失败的尝试 |
| TargetInvocations | 计数 | 向目标发出的呼叫；一个呼叫可以携带一批事件 |
| RetryInvocationAttempts | 计数 | 仅在重试时发出，值为重试深度：第二次尝试为 1，第三次尝试为 2。样本数是重试次数 |
| EventsDelivered | 计数 | 目标接受的事件 |
| EgressBytes | 字节 | 传送到目标的字节 |
| EventTransformationFailures | 计数 | Transformer或通用目标表达式Input失败的事件 |
| IngestionToInvocationStartTime | 毫秒 | 从活动到达公交车到目标通话开始的时间。在调用目标之前尝试失败时不发出 |
| IngestionToInvocationEndTime | 毫秒 | 从活动到达公交车到目标通话结束的时间 |
| OnFailureDestinationDelivered | 计数 | 写入死信队列的记录 |
| OnFailureDestinationFailed | 计数 | 无法写入死信队列的记录 |
| EventsDropped | 计数 | 耗尽重试次数的事件没有死信队列来记录它们 |
| ApproximateBacklogAge | 毫秒 | 订阅者尚未交付的最早活动的年龄 |
| SubscriberLogRecordsDropped | 计数 | 无法写入的日志记录，因为尽最大努力传送日志 |
您账户的公交车数量也会在`AWS/Usage`命名空间中报告为`Service``EventBridge`和`ResourceCount`以开头的`Resource`值`EventsV2/`，因此当您接近总线配额时，您可以发出警报。有关配额，请参阅[自定义事件总线配额](eb-quota.md#eb-custom-bus-quotas)。
## 发布指标
Ev `PutEvents` er `PutRawEvents` y and 调用还会在`AWS/EventsV2`命名空间中生成指标，因此您可以对总线的发布调用受限或失败发出警报，例如将`EventBus`维度设置为。`PublishEventsApproximateThrottledCallCount` `orders`公交车所有者的账户会收到所有发布的指标。向其不拥有的公交车发布信息的账户也会在自己的账户中接收这些信息，用于自己的通话。
| 指标 | 单位 | 含义 |
| --- | --- | --- |
| PublishEventsApproximateCallCount | 计数 | 发布接到的电话 |
| PublishEventsApproximateSuccessCallCount | 计数 | 发布返回 HTTP 200 的调用 |
| PublishEventsApproximateFailedCallCount | 计数 | 发布返回错误的调用 |
| PublishEventsApproximateThrottledCallCount | 计数 | 使用以下方式发布被拒绝的呼叫 ThrottlingException |
| PublishEventsEntryCount | 计数 | 发布电话会议中的条目 |
| PublishEventsFailedEntriesCount | 计数 | 在接受的呼叫中失败的条目，在响应中报告为失败的条目 |
| PublishEventsIngressBytes | 字节 | 存储的事件负载的字节数。对于不存储任何内容的呼叫，不是 0。以账单上的入口行项目为趋势，将每个条目四舍五入到整个 KB。 |
维度取决于指标和发布者。
+ 发布的每个指标都只包含一个`EventBus`维度：总线的总数。
+ 对于通过事件源到达的事件，计数指标也与`EventBus`和一起发布`EventSource`，因此您可以查看一个来源的份额。`PublishEventsIngressBytes`没有`EventSource`故障。
+ `PublishEventsIngressBytes`还会使用`EventBus`和发布给总线所有者`PublisherAccount`，因此总线所有者可以看到每个发布帐户存储了多少字节。
## 订阅者日志
订阅者可以记录其尝试提供的每个事件的发生情况。登录是按订阅者进行的，创建订阅者时会关闭，因此，在您设置之前，新订阅者不会记录任何内容`LogConfiguration`。每条记录都是一个 JSON 文档`message_type`，上面写着它所描述的内容。
+ `SUBSCRIBER_MATCHED`：事件与订阅者的筛选条件相匹配并进入了交付状态。
+ `EVENT_DELIVERY_ATTEMPT`: 一次尝试调用目标，包括其结果、尝试次数和持续时间。这是本节其余部分描述的记录。
+ `EVENT_TRANSFORMATION_FAILURE`: `Transformer` 或通用目标`Input`表达式因事件而失败，出现错误。
+ `ON_FAILURE_DESTINATION_DELIVERY_ATTEMPT`: 一次尝试将记录写入死信队列。
尽最大努力传送日志。无法写入的记录将计入`SubscriberLogRecordsDropped`指标，而不是无限期重试。当使用客户管理的密钥对总线进行加密时， EventBridge 会在离开该密钥之前对该密钥下的每条记录的有效负载字段进行加密 EventBridge，因此无法使用该密钥的目标账户在没有密钥的情况下可以看到该记录。重播赛事的记录继续 `details.delivery_type``REPLAY`；直播赛事的记录。`LIVE`
### 生成记录的两个设置
在读取一条记录之前，必须存在两个独立的设置。
1. **订阅者的日志级别。**`LogConfiguration.Level`决定 EventBridge 发射哪些记录。默认为`OFF`，不发射。
1. **A CloudWatch 日志传输。**记录通过 Amazon Logs 销售的 CloudWatch 日志传输机制到达您手中，该机制将订阅者与您拥有的目的地配对。没有它，记录就无处可去，也不会单独出现日志组。
在开始诊断配送问题之前（而不是之后）进行这两个设置。只有订阅者才有日志配置。总线和事件源都没有，因此您可以一次只开启一个订阅者的登录功能。`LogConfiguration`有两个成员。
`Level`
记录的最低级别。其下方的记录不会被发出。`OFF`，默认情况下，什么都不发射。`ERROR`仅发出失败的交付尝试。`INFO`发出每一次交付尝试，包括成功的交付尝试。
`IncludePayload`
记录是否携带您的事件负载。`ON_ERROR_ONLY`，默认，仅将其保留在失败记录中。`FULL`将其记录在每张唱片上。请参阅[日志记录中的有效载荷](#eb-custom-bus-observability-payload)。
您可以在创建订阅者`LogConfiguration`时进行设置，也可以稍后使用`UpdateSubscriber`。更新无需重新创建订阅者即可生效。创建响应和更新响应都不会回显该字段，因此请使用确认存储的值`DescribeSubscriber`，这会返回该值。
### 为一位订阅者开启登录功能
以下步骤记录一个现有订阅者的每次交付尝试，并将记录传送到同一账户中的 CloudWatch 日志日志组。第一个命令是 EventBridge 调用，其余是 CloudWatch 日志调用。首先提高订阅者的日志级别。`INFO`记录成功和失败，这可以告诉您事件是否已交付。
```
aws eventsv2 update-subscriber \
--subscriber-arn arn:aws:events:us-east-1:111122223333:subscriber/large-orders/EXAMPLE1234567890abcdef \
--log-configuration '{ "Level": "INFO", "IncludePayload": "FULL" }'
```
接下来，创建目标日志组。名称必须以开头`/aws/vendedlogs/`。 CloudWatch 日志仅在该前缀下为您管理交付资源策略；对于外部的日志组，您必须自己管理该策略。
```
aws logs create-log-group \
--log-group-name /aws/vendedlogs/large-orders-delivery
```
创建传输源。`--resource-arn`这是订阅者ARN，这使来源产生了该订阅者的记录。设置`--log-type`为与您配置的级别相匹配：`INFO_LOGS`for `Level` `INFO` 或 `ERROR_LOGS` for `Level` `ERROR`。
```
aws logs put-delivery-source \
--name large-orders-source \
--resource-arn arn:aws:events:us-east-1:111122223333:subscriber/large-orders/EXAMPLE1234567890abcdef \
--log-type INFO_LOGS
```
创建命名日志组的传送目的地。响应包含下一个命令需要的目标 ARN。
```
aws logs put-delivery-destination \
--name large-orders-destination \
--delivery-destination-configuration destinationResourceArn=arn:aws:logs:us-east-1:111122223333:log-group:/aws/vendedlogs/large-orders-delivery
```
最后，将源与目标配对。使用先前响应中的目标 ARN。
```
aws logs create-delivery \
--delivery-source-name large-orders-source \
--delivery-destination-arn {{destination-arn}}
```
记录现在出现在日志组中。它们到达的时间比交付本身晚，因为日志管道会对它们进行批处理，因此，当您在发布后立即读取日志组时，请留出延迟。这种布线的三个特性决定了它的伸展距离。目标是一个日志组、一个 Amazon S3 存储桶或一个 Amazon Data Firehose 流，上面的命令是相同的：只是`destinationResourceArn`变化。一次传送恰好将一个来源与一个目的地配对，因此将订阅者的记录发送到第二个目的地需要第二次交付。目的地可以与订阅者位于不同的账户中，在这种情况下，目标账户必须调用`PutDeliveryDestinationPolicy`目的地才能允许交付，中央账户就是这样为其不拥有的订阅者收集记录的。
### 读取交付记录
EventBridge 每个事件的每次交付尝试都会发出一条记录。四个字段位于顶层。`message_type``EVENT_DELIVERY_ATTEMPT`用于尝试交付；本节开头列出了其他类型。`resource_arn`是尝试的订阅者的 ARN，这是您区分共享一个日志组的订阅者的方式。`log_level`是记录本身的级别：成功的尝试是`INFO`，失败的尝试是`ERROR`，这就是为什么`Level``ERROR`仍然记录失败的原因。`details`是一个保存交付状态的对象，它包含您构建查询和警报的字段。
`outcome` 和 `attempt_count`
`SUCCESS`或者`FAILURE`是这次尝试，以及是哪次尝试，因此重试次数是可以计算的。
`terminal_kind`
在一条记录上显示事件是如何结束的：`EVENTS_DELIVERED``ON_FAILURE_DESTINATION_DELIVERED`、或者重试用完但未配置失败目标的`EVENTS_DROPPED`时间。
`target_arn` 和 `target_properties`
尝试针对的目标以及订阅者为此事件解析的目标参数。`target_properties`当订阅者未配置任何参数时，省略。
`ingestion_to_start_latency_ms` 和 `ingestion_to_complete_latency_ms`
从事件摄取到本次尝试开始和结束的毫秒数。
`target_input`
逐字发送到目标的字节。这是一个有效载荷字段；请参阅[日志记录中的有效载荷](#eb-custom-bus-observability-payload)。
`event_detail`、`event_metadata` 和 `event_system_metadata`
该活动如 EventBridge 期举行。`event_system_metadata`携带您关联记录所依据的标识符。`event_detail`仅当它与不同时出现`target_input`，订阅者有变压器时就是这种情况。
要诊断从未送达的配送，请按此顺序阅读订阅者的记录。`outcome`说明是否完全 EventBridge 达到了目标。`attempt_count`说明它是否仍在重试，因为没有`terminal_kind`记录的事件尚未完成。`terminal_kind`说明它是如何结束的，并将一封死信的事件与被删除的事件区分开来。`target_arn``target_properties`，然后`target_input`说出发送了什么以及发送到哪里，这就是变压器或目标参数问题出现的地方。尝试失败后，记录中会立即显示失败，因此您不必等待重试次数用完。有关完整过程，请参阅[疑难解答：你发布了但没有到达目标](eb-custom-bus-subscribers.md#eb-custom-bus-subscribers-nothing-arrived)。
### 日志记录中的有效载荷
`IncludePayload`控制两个字段而不控制其他字段：`details.target_input`和`details.event_detail`。无论您选择哪个值，所有其他字段都会发出，因此将有效载荷排除在记录之外的订阅者仍会报告结果、目标、尝试次数和延迟。`FULL`将有效载荷嵌入到每条记录中，包括成功交付的记录。`ON_ERROR_ONLY`，默认，仅将其嵌入失败记录中，并从记录中省略这两个字段以成功交付。
**重要**
载有有效载荷的日志记录会携带您的数据。使用`FULL`，日志组保存订阅者交付的每个事件正文的副本，任何能读取该日志组的人都可以读取这些正文。在调试订阅者`FULL`时使用，然后将其返回到`ON_ERROR_ONLY`。这限制了你存储的曝光量和音量。
## API 调用 Amazon CloudTrail
订阅者日志记录的是交付情况，而不是您为配置它们而拨打的电话。 Amazon CloudTrail 记录管理 API 调用，因此对总线、订阅者或事件源的更改可以从您的跟踪中进行审计，而不是来自日志组。有关如何与 EventBridge 集成的信息 CloudTrail，请参见[日志记录 Amazon EventBridge 使用 API 调用 Amazon CloudTrail](logging-using-cloudtrail.md)。