

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 自訂事件匯流排的可觀測性：指標、日誌和 CloudTrail
<a name="eb-custom-bus-observability"></a>

三個來源會告訴您匯流排及其訂閱者正在做什麼。`AWS/EventsV2` 命名空間中的 Amazon CloudWatch 指標會針對每個訂閱者開啟；當交付失敗時發出警示、在 `OnFailureDestinationDelivered`或 上發出警示`EventsDropped`，或在`EventDeliveryAttempts`負上發出警示，`EventsDelivered`並顯示指標數學。訂閱者日誌會將每次交付嘗試記錄為 JSON 記錄，直到您在訂閱者`LogConfiguration.Level`上設定為止。 會 AWS CloudTrail 記錄建立和變更匯流排、訂閱者和事件來源的 API 呼叫。

## 指標
<a name="eb-custom-bus-observability-metrics"></a>

訂閱者指標具有兩個維度，`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`命名空間中報告為 `ResourceCount` ，`Service``EventBridge`並以 開頭`Resource`的值`EventsV2/`，因此您可以在接近匯流排配額時發出警示。如需配額，請參閱 [自訂事件匯流排配額](eb-quota.md#eb-custom-bus-quotas)。

## 發布指標
<a name="eb-custom-bus-observability-publish-metrics"></a>

每個 `PutEvents`和 `PutRawEvents`呼叫也會在`AWS/EventsV2`命名空間中產生指標，因此您可以對匯流排的調節或失敗發佈呼叫發出警示，例如在 上，`PublishEventsApproximateThrottledCallCount`將`EventBus`維度設定為 `orders`。匯流排擁有者的帳戶會收到每個發佈指標。發佈到其未擁有的匯流排的帳戶也會在其自己的帳戶中接收它們以進行自己的呼叫。


| 指標 | 單位 | 意義 | 
| --- | --- | --- | 
| PublishEventsApproximateCallCount | 計數 | 發佈收到的呼叫 | 
| PublishEventsApproximateSuccessCallCount | 計數 | 發佈傳回 HTTP 200 的呼叫 | 
| PublishEventsApproximateFailedCallCount | 計數 | 發佈傳回錯誤的呼叫 | 
| PublishEventsApproximateThrottledCallCount | 計數 | 發佈使用 拒絕的呼叫 ThrottlingException | 
| PublishEventsEntryCount | 計數 | 發佈呼叫中的項目 | 
| PublishEventsFailedEntriesCount | 計數 | 在已接受的呼叫中失敗的項目，在回應中報告為失敗的項目 | 
| PublishEventsIngressBytes | 位元組 | 儲存的事件承載位元組。不存在，而不是 0，用於未存放任何內容的呼叫。帳單上輸入明細項目的趨勢，會將每個項目四捨五入至整個 KB。 | 

維度取決於指標和發佈者。
+ 每個指標只會以 `EventBus` 維度發佈：匯流排的總計。
+ 對於透過事件來源抵達的事件，計數指標也會使用 `EventBus`和 發佈`EventSource`，因此您可以查看一個來源的共享。 `PublishEventsIngressBytes` 沒有`EventSource`明細。
+ `PublishEventsIngressBytes` 也會使用 `EventBus`和 發佈至匯流排擁有者`PublisherAccount`，因此匯流排擁有者可以查看每個發佈帳戶儲存的位元組數。

## 訂閱者日誌
<a name="eb-custom-bus-observability-logs"></a>

訂閱者可以記錄其嘗試傳遞的每個事件所發生的情況。記錄是每個訂閱者，並在您建立時關閉，因此在您設定 之前，新的訂閱者不會記錄任何內容`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`。

### 產生記錄的兩個設定
<a name="eb-custom-bus-observability-configuration"></a>

兩個獨立設定必須同時存在，您才能讀取單一記錄。

1. **訂閱者的日誌層級。** 會`LogConfiguration.Level`決定 EventBridge 發出的記錄。它預設為 `OFF`，不會發出任何 。

1. **CloudWatch Logs 交付。**記錄會透過 Amazon CloudWatch Logs 提供的日誌交付機制與您聯絡，這會將訂閱者與您擁有的目的地配對。如果沒有它，記錄就沒有可登陸的位置，也沒有日誌群組單獨顯示。

在您開始診斷交付問題之前，請進行這兩個設定，而不是在之後進行。只有訂閱者具有日誌組態。匯流排和事件來源沒有，因此您一次開啟一個訂閱者的記錄。 `LogConfiguration` 有兩個成員。

`Level`  
記錄的最低層級。不會發出下方的記錄。 預設 `OFF`不會發出任何 。 `ERROR` 只會發出失敗的交付嘗試。 `INFO` 會發出每次交付嘗試，包括成功的交付嘗試。

`IncludePayload`  
記錄是否承載您的事件承載。 `ON_ERROR_ONLY`是預設值，只會承載失敗記錄。 會`FULL`承載每個記錄。請參閱 [日誌記錄中的承載](#eb-custom-bus-observability-payload)。

您可以在建立訂閱者`LogConfiguration`時設定 ，或稍後使用 設定 `UpdateSubscriber`。更新會在不重新建立訂閱者的情況下生效。建立回應和更新回應都不會回傳 欄位，因此請使用 確認儲存的值`DescribeSubscriber`，這會傳回它。

### 開啟一個訂閱者的記錄
<a name="eb-custom-bus-observability-setup"></a>

下列步驟會記錄一個現有訂閱者的每次交付嘗試，並將記錄交付至相同帳戶中的 CloudWatch Logs 日誌群組。第一個命令是 EventBridge 呼叫，其餘命令是 CloudWatch Logs 呼叫。從提高訂閱者的日誌層級開始。 會`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 Logs 只會在該字首下為您管理交付資源政策；對於外部的日誌群組，您必須自行管理該政策。

```
aws logs create-log-group \
    --log-group-name /aws/vendedlogs/large-orders-delivery
```

建立交付來源。`--resource-arn` 它是訂閱者 ARN，這是讓來源產生訂閱者記錄的原因。`--log-type` 設定為符合您設定的關卡：`INFO_LOGS`適用於 `Level` `INFO`，或`ERROR_LOGS`適用於 `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`上呼叫 以允許交付，這是中央帳戶收集其未擁有之訂閱者記錄的方式。

### 讀取交付記錄
<a name="eb-custom-bus-observability-records"></a>

EventBridge 會針對每個事件每次交付嘗試發出一筆記錄。四個欄位位於最上層。 `message_type` `EVENT_DELIVERY_ATTEMPT`用於交付嘗試；其他類型則列在本節開頭。 `resource_arn` 是嘗試的訂閱者 ARN，這是您分隔共用一個日誌群組的訂閱者的方式。 `log_level` 是記錄本身的層級：成功的嘗試是 `INFO`，失敗的嘗試是 `ERROR`，這就是為什麼`Level``ERROR`仍然記錄失敗。 `details` 是保留交付狀態的物件，它保留您建置查詢和警示的欄位。

`outcome` 和 `attempt_count`  
`SUCCESS` 或 `FAILURE` 進行此嘗試，以及嘗試的次數，因此可計入重試次數。

`terminal_kind`  
出現在指出事件如何結束的一個記錄上：`ON_FAILURE_DESTINATION_DELIVERED`、 `EVENTS_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)。

### 日誌記錄中的承載
<a name="eb-custom-bus-observability-payload"></a>

`IncludePayload` 控制兩個欄位，沒有其他欄位： `details.target_input`和 `details.event_detail`。每隔一個欄位都會發出您選擇的任何值，因此讓承載從其記錄中保留的訂閱者仍會報告結果、目標、嘗試計數和延遲。 會將承載`FULL`嵌入每個記錄中，包括成功交付的記錄。`ON_ERROR_ONLY`，預設值為 ，只會將其內嵌在失敗記錄中，並省略記錄中的兩個欄位，以便成功交付。

**重要**  
承載的日誌記錄會攜帶您的資料。使用 `FULL`，日誌群組會保留訂閱者交付的每個事件內文的副本，而且任何可以讀取日誌群組的人都可以讀取這些內文。在除錯訂閱者`FULL`時使用 ，然後將其傳回 `ON_ERROR_ONLY`。這會同時限制曝光和您存放的磁碟區。

## 中的 API 呼叫 AWS CloudTrail
<a name="eb-custom-bus-observability-cloudtrail"></a>

訂閱者日誌記錄傳送，而不是您進行設定呼叫。 AWS CloudTrail 會記錄管理 API 呼叫，因此可從您的追蹤稽核匯流排、訂閱者或事件來源的變更，而不是從日誌群組進行稽核。如需 EventBridge 如何與 CloudTrail 整合，請參閱 [使用 記錄 Amazon EventBridge API 呼叫 AWS CloudTrail](logging-using-cloudtrail.md)。