Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pengamatan untuk Bus Peristiwa Kustom: metrik, log, dan CloudTrail
Tiga sumber memberi tahu Anda apa yang dilakukan bus dan pelanggannya. CloudWatch Metrik Amazon di `AWS/EventsV2` namespace aktif untuk setiap pelanggan; untuk alarm ketika pengiriman gagal, alarm aktif`EventsDropped`, `OnFailureDestinationDelivered` atau `EventDeliveryAttempts` minus `EventsDelivered` dengan matematika metrik. Log pelanggan mencatat setiap upaya pengiriman sebagai catatan JSON; log tersebut mati sampai Anda mengatur `LogConfiguration.Level` pelanggan. AWS CloudTrail merekam panggilan API yang membuat dan mengubah bus, pelanggan, dan sumber acara.
## Metrik-metrik
Metrik pelanggan membawa dua dimensi, `EventBus` dan`Subscriber`, masing-masing memegang sumber daya ARN. Ketika pelanggan memiliki akun yang berbeda dari bus, EventBridge juga memancarkan metrik dengan `EventBus` dan `SubscriberAccount` sehingga pemilik bus dapat melihat konsumsi per akun. Tabel berikut mencantumkan metrik.
| Metrik | Unit | Arti |
| --- | --- | --- |
| FilterEvaluated | Hitungan | Peristiwa dievaluasi terhadap filter pelanggan |
| FilterMatched | Hitungan | Acara yang cocok dengan setiap filter |
| EventDeliveryAttempts | Hitungan | Upaya pengiriman, dihitung per acara. Kurangi EventsDelivered untuk menghitung upaya yang gagal |
| TargetInvocations | Hitungan | Panggilan yang dilakukan ke target; satu panggilan dapat membawa sejumlah acara |
| RetryInvocationAttempts | Hitungan | Dipancarkan hanya pada percobaan ulang, dinilai sebagai kedalaman percobaan ulang: upaya kedua adalah 1, yang ketiga adalah 2. Jumlah sampel adalah jumlah percobaan ulang |
| EventsDelivered | Hitungan | Acara yang diterima target |
| EgressBytes | Byte | Byte dikirim ke target |
| EventTransformationFailures | Hitungan | Peristiwa yang Transformer ekspresi target universalnya gagal Input |
| IngestionToInvocationStartTime | Milidetik | Waktu dari kedatangan acara di bus hingga dimulainya panggilan target. Tidak dipancarkan ketika upaya gagal sebelum memanggil target |
| IngestionToInvocationEndTime | Milidetik | Waktu dari kedatangan acara di bus hingga akhir panggilan target |
| OnFailureDestinationDelivered | Hitungan | Catatan ditulis ke antrian huruf mati |
| OnFailureDestinationFailed | Hitungan | Catatan yang tidak dapat ditulis ke antrian huruf mati |
| EventsDropped | Hitungan | Peristiwa yang menghabiskan waktu percobaan ulang tanpa antrian huruf mati untuk merekamnya |
| ApproximateBacklogAge | Milidetik | Usia acara tertua yang belum disampaikan pelanggan |
| SubscriberLogRecordsDropped | Hitungan | Catatan log yang tidak dapat ditulis, karena pengiriman log adalah upaya terbaik |
Jumlah bus akun Anda juga dilaporkan di `AWS/Usage` namespace seperti `ResourceCount` dengan `Service` `EventBridge` dan `Resource` nilai yang dimulai dengan`EventsV2/`, sehingga Anda dapat alarm saat mendekati kuota bus. Untuk kuota, lihat[Kuota Bus Acara Kustom](eb-quota.md#eb-custom-bus-quotas).
## Menerbitkan metrik
Setiap `PutRawEvents` panggilan `PutEvents` dan juga menghasilkan metrik di `AWS/EventsV2` namespace, sehingga Anda dapat memberi alarm pada panggilan publikasi yang dibatasi atau gagal untuk bus, misalnya `PublishEventsApproximateThrottledCallCount` dengan `EventBus` dimensi yang disetel ke. `orders` Akun pemilik bus menerima setiap metrik publikasi. Akun yang diterbitkan ke bus yang tidak dimilikinya juga menerimanya, dalam akunnya sendiri, untuk panggilannya sendiri.
| Metrik | Unit | Arti |
| --- | --- | --- |
| PublishEventsApproximateCallCount | Hitungan | Publikasikan panggilan yang diterima |
| PublishEventsApproximateSuccessCallCount | Hitungan | Publikasikan panggilan yang mengembalikan HTTP 200 |
| PublishEventsApproximateFailedCallCount | Hitungan | Publikasikan panggilan yang mengembalikan kesalahan |
| PublishEventsApproximateThrottledCallCount | Hitungan | Publikasikan panggilan yang ditolak dengan ThrottlingException |
| PublishEventsEntryCount | Hitungan | Entri dalam panggilan publikasi |
| PublishEventsFailedEntriesCount | Hitungan | Entri yang gagal dalam panggilan yang diterima, dilaporkan dalam respons sebagai entri yang gagal |
| PublishEventsIngressBytes | Byte | Byte muatan acara disimpan. Absen, bukan 0, untuk panggilan yang tidak menyimpan apa pun. Tren dengan item baris masuk pada tagihan Anda, yang membulatkan setiap entri hingga keseluruhan KB. |
Dimensi tergantung pada metrik dan siapa yang menerbitkan.
+ Setiap metrik dipublikasikan dengan `EventBus` dimensi saja: total untuk bus.
+ Untuk acara yang tiba melalui sumber peristiwa, metrik hitungan juga dipublikasikan dengan `EventBus` dan`EventSource`, sehingga Anda dapat melihat bagian satu sumber. `PublishEventsIngressBytes`tidak memiliki `EventSource` kerusakan.
+ `PublishEventsIngressBytes`juga dipublikasikan ke pemilik bus dengan `EventBus` dan`PublisherAccount`, sehingga pemilik bus dapat melihat berapa banyak byte yang disimpan setiap akun penerbitan.
## Log pelanggan
Pelanggan dapat merekam apa yang terjadi pada setiap peristiwa yang dicoba disampaikannya. Logging adalah per pelanggan dan mati saat Anda membuatnya, jadi pelanggan baru tidak mencatat apa pun sampai Anda menyetel`LogConfiguration`. Setiap catatan adalah dokumen JSON dengan `message_type` yang mengatakan apa yang dideskripsikan.
+ `SUBSCRIBER_MATCHED`: acara cocok dengan filter pelanggan dan memasukkan pengiriman.
+ `EVENT_DELIVERY_ATTEMPT`: satu upaya untuk memanggil target, dengan hasilnya, jumlah percobaan, dan durasinya. Ini adalah catatan yang dijelaskan oleh bagian ini lainnya.
+ `EVENT_TRANSFORMATION_FAILURE`: `Input` ekspresi `Transformer` atau target universal gagal untuk suatu peristiwa, dengan kesalahan.
+ `ON_FAILURE_DESTINATION_DELIVERY_ATTEMPT`: satu upaya untuk menulis catatan ke antrian huruf mati.
Pengiriman log adalah upaya terbaik. Catatan yang tidak dapat ditulis dihitung dalam `SubscriberLogRecordsDropped` metrik daripada dicoba ulang tanpa batas waktu. Ketika bus dienkripsi dengan kunci yang dikelola pelanggan, EventBridge mengenkripsi bidang muatan dari setiap catatan di bawah kunci itu sebelum pergi EventBridge, sehingga akun tujuan yang tidak dapat menggunakan kunci melihat catatan tanpa mereka. Rekor acara yang diputar ulang membawa `details.delivery_type``REPLAY`; acara langsung dibawa. `LIVE`
### Dua pengaturan yang menghasilkan rekaman
Dua pengaturan independen harus ada sebelum Anda dapat membaca satu catatan.
1. **Tingkat log pelanggan. **`LogConfiguration.Level`memutuskan rekaman mana yang dipan EventBridge carkan. Defaultnya`OFF`, yang tidak memancarkan apa-apa.
1. **Pen CloudWatch giriman Logs. ** Catatan menjangkau Anda melalui mekanisme pengiriman CloudWatch log yang dijual Amazon Logs, yang memasangkan pelanggan dengan tujuan yang Anda miliki. Tanpanya, catatan tidak memiliki tempat untuk mendarat dan tidak ada grup log yang muncul dengan sendirinya.
Buat kedua pengaturan sebelum Anda mulai mendiagnosis masalah pengiriman daripada setelahnya. Hanya pelanggan yang memiliki konfigurasi log. Bus dan sumber acara tidak memiliki, jadi Anda mengaktifkan log pada satu pelanggan pada satu waktu. `LogConfiguration`memiliki dua anggota.
`Level`
Tingkat minimum rekor. Catatan di bawahnya tidak dipancarkan. `OFF`, default, tidak memancarkan apa pun. `ERROR`hanya mengeluarkan upaya pengiriman yang gagal. `INFO`memancarkan setiap upaya pengiriman, termasuk yang berhasil.
`IncludePayload`
Apakah catatan membawa muatan acara Anda. `ON_ERROR_ONLY`, default, membawanya pada catatan kegagalan saja. `FULL`membawanya pada setiap catatan. Lihat [Muatan dalam catatan log](#eb-custom-bus-observability-payload).
Anda dapat mengatur `LogConfiguration` kapan Anda membuat pelanggan, atau nanti dengan`UpdateSubscriber`. Pembaruan berlaku tanpa membuat ulang pelanggan. Baik respons buat maupun respons pembaruan tidak menggemakan bidang kembali, jadi konfirmasikan nilai yang disimpan dengan`DescribeSubscriber`, yang mengembalikannya.
### Aktifkan logging untuk satu pelanggan
Langkah-langkah berikut mencatat setiap upaya pengiriman untuk satu pelanggan yang ada dan mengirimkan catatan ke grup CloudWatch log log di akun yang sama. Perintah pertama adalah EventBridge panggilan, dan sisanya adalah panggilan CloudWatch Log. Mulailah dengan menaikkan level log pelanggan. `INFO`mencatat keberhasilan serta kegagalan, yang memberi tahu Anda apakah suatu acara disampaikan sama sekali.
```
aws eventsv2 update-subscriber \
--subscriber-arn arn:aws:events:us-east-1:111122223333:subscriber/large-orders/EXAMPLE1234567890abcdef \
--log-configuration '{ "Level": "INFO", "IncludePayload": "FULL" }'
```
Selanjutnya, buat grup log tujuan. Nama harus dimulai dengan`/aws/vendedlogs/`. CloudWatch Log mengelola kebijakan sumber daya pengiriman untuk Anda hanya di bawah awalan itu; untuk grup log di luarnya, Anda harus mengelola kebijakan itu sendiri.
```
aws logs create-log-group \
--log-group-name /aws/vendedlogs/large-orders-delivery
```
Buat sumber pengiriman. Ini `--resource-arn` adalah ARN pelanggan, yang membuat sumber menghasilkan catatan pelanggan itu. Set `--log-type` el agar sesuai dengan level yang Anda konfigurasikan: `INFO_LOGS` untuk `Level``INFO`, atau `ERROR_LOGS` untuk `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
```
Buat tujuan pengiriman dengan nama grup log. Respons berisi ARN tujuan, yang dibutuhkan perintah berikutnya.
```
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
```
Terakhir, pasangkan sumber dengan tujuan. Gunakan ARN tujuan dari respons sebelumnya.
```
aws logs create-delivery \
--delivery-source-name large-orders-source \
--delivery-destination-arn {{destination-arn}}
```
Catatan sekarang muncul di grup log. Mereka tiba lebih lambat dari pengiriman itu sendiri, karena pipeline log mengelompokkannya, jadi izinkan jeda itu saat Anda membaca grup log tepat setelah penerbitan. Tiga sifat kabel ini menentukan seberapa jauh peregangan. Tujuan adalah grup log, bucket Amazon S3, atau aliran Amazon Data Firehose, dan perintah di atas sama untuk masing-masing: hanya `destinationResourceArn` perubahan. Satu pengiriman memasangkan tepat satu sumber dengan tepat satu tujuan, jadi mengirim catatan pelanggan ke tujuan kedua membutuhkan pengiriman kedua. Tujuan dapat berada di akun yang berbeda dari pelanggan, dan dalam hal ini akun tujuan harus memang `PutDeliveryDestinationPolicy` gil tujuan untuk memungkinkan pengiriman, yaitu bagaimana akun pusat mengumpulkan catatan untuk pelanggan yang tidak dimilikinya.
### Membaca catatan pengiriman
EventBridge memancarkan satu catatan per upaya pengiriman per acara. Empat bidang berada di tingkat atas. `message_type`adalah `EVENT_DELIVERY_ATTEMPT` untuk upaya pengiriman; jenis lainnya tercantum di awal bagian ini. `resource_arn`adalah ARN pelanggan yang melakukan upaya, yang merupakan cara Anda memisahkan pelanggan yang berbagi satu grup log. `log_level`adalah tingkat catatan itu sendiri: upaya yang berhasil`INFO`, dan upaya yang gagal adalah`ERROR`, itulah sebabnya `Level` `ERROR` masih mencatat kegagalan. `details`adalah objek yang memegang status pengiriman, dan menyimpan bidang tempat Anda membuat kueri dan alarm.
`outcome` dan `attempt_count`
`SUCCESS`atau `FAILURE` untuk upaya ini, dan upaya mana, jadi percobaan ulang dapat dihitung.
`terminal_kind`
Hadir pada satu catatan yang mengatakan bagaimana acara berakhir:`EVENTS_DELIVERED`,`ON_FAILURE_DESTINATION_DELIVERED`, atau `EVENTS_DROPPED` ketika percobaan ulang habis dan tidak ada tujuan pada kegagalan yang dikonfigurasi.
`target_arn` dan `target_properties`
Target yang dilakukan oleh upaya tersebut, dan parameter target yang diselesaikan pelanggan untuk acara ini. `target_properties`dihilangkan ketika pelanggan tidak mengonfigurasi parameter.
`ingestion_to_start_latency_ms` dan `ingestion_to_complete_latency_ms`
Milidetik dari penyerapan peristiwa hingga awal dan hingga akhir upaya ini.
`target_input`
Byte dikirim ke target, kata demi kata. Ini adalah bidang muatan; lihat[Muatan dalam catatan log](#eb-custom-bus-observability-payload).
`event_detail`, `event_metadata`, dan `event_system_metadata`
Acara seperti yang EventBridge diadakan. `event_system_metadata`membawa pengidentifikasi yang Anda gunakan untuk menghubungkan catatan. `event_detail`muncul hanya ketika berbeda dari`target_input`, yang merupakan kasus ketika pelanggan memiliki transformator.
Untuk mendiagnosis pengiriman yang tidak pernah tiba, baca catatan pelanggan dalam urutan ini. `outcome`mengatakan apakah EventBridge mencapai target sama sekali. `attempt_count`mengatakan apakah masih mencoba lagi, karena acara tanpa `terminal_kind` catatan belum selesai. `terminal_kind`mengatakan bagaimana itu berakhir, dan memisahkan peristiwa yang berhuruf mati dari yang dijatuhkan. `target_arn`,`target_properties`, dan `target_input` katakan apa yang dikirim dan di mana, di mana masalah parameter transformator atau target muncul. Kegagalan terlihat dalam catatan segera setelah upaya gagal, jadi Anda tidak perlu menunggu percobaan ulang habis. Untuk prosedur lengkapnya, lihat [Pemecahan masalah: Anda menerbitkan dan tidak ada yang sampai pada target](eb-custom-bus-subscribers.md#eb-custom-bus-subscribers-nothing-arrived).
### Muatan dalam catatan log
`IncludePayload`mengontrol dua bidang dan tidak ada yang lain: `details.target_input` dan`details.event_detail`. Setiap bidang lain dipancarkan nilai apa pun yang Anda pilih, sehingga pelanggan yang menjaga muatan keluar dari catatannya masih melaporkan hasil, target, jumlah upaya, dan latensi. `FULL`menyematkan payload di setiap catatan, termasuk catatan untuk pengiriman yang berhasil. `ON_ERROR_ONLY`, default, menyematkannya dalam catatan kegagalan saja, dan menghilangkan kedua bidang dari catatan untuk pengiriman yang berhasil.
**penting**
Catatan log yang membawa muatan membawa data Anda. Dengan`FULL`, grup log menyimpan salinan setiap badan peristiwa yang dikirimkan pelanggan, dan siapa pun yang dapat membaca grup log dapat membaca badan tersebut. Gunakan `FULL` saat Anda men-debug pelanggan, lalu kembalikan ke`ON_ERROR_ONLY`. Itu membatasi eksposur dan volume yang Anda simpan.
## Panggilan API masuk AWS CloudTrail
Log pelanggan merekam pengiriman, bukan panggilan yang Anda lakukan untuk mengonfigurasinya. AWS CloudTrail merekam panggilan API manajemen, sehingga perubahan ke bus, pelanggan, atau sumber peristiwa dapat diaudit dari jejak Anda daripada dari grup log. Untuk bagaimana EventBridge terintegrasi dengan CloudTrail, lihat[Logging panggilan Amazon EventBridge API menggunakan AWS CloudTrail](logging-using-cloudtrail.md).