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 aktifEventsDropped, 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 danSubscriber, 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 denganEventsV2/, sehingga Anda dapat alarm saat mendekati kuota bus. Untuk kuota, lihatKuota Bus Acara Kustom.
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
EventBusdimensi saja: total untuk bus.Untuk acara yang tiba melalui sumber peristiwa, metrik hitungan juga dipublikasikan dengan
EventBusdanEventSource, sehingga Anda dapat melihat bagian satu sumber.PublishEventsIngressBytestidak memilikiEventSourcekerusakan.PublishEventsIngressBytesjuga dipublikasikan ke pemilik bus denganEventBusdanPublisherAccount, 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 menyetelLogConfiguration. 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:InputekspresiTransformeratau 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_typeREPLAY; acara langsung dibawa. LIVE
Dua pengaturan yang menghasilkan rekaman
Dua pengaturan independen harus ada sebelum Anda dapat membaca satu catatan.
-
Tingkat log pelanggan.
LogConfiguration.Levelmemutuskan rekaman mana yang dipan EventBridge carkan. DefaultnyaOFF, yang tidak memancarkan apa-apa. -
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. LogConfigurationmemiliki dua anggota.
Level-
Tingkat minimum rekor. Catatan di bawahnya tidak dipancarkan.
OFF, default, tidak memancarkan apa pun.ERRORhanya mengeluarkan upaya pengiriman yang gagal.INFOmemancarkan setiap upaya pengiriman, termasuk yang berhasil. IncludePayload-
Apakah catatan membawa muatan acara Anda.
ON_ERROR_ONLY, default, membawanya pada catatan kegagalan saja.FULLmembawanya pada setiap catatan. Lihat Muatan dalam catatan log.
Anda dapat mengatur LogConfiguration kapan Anda membuat pelanggan, atau nanti denganUpdateSubscriber. Pembaruan berlaku tanpa membuat ulang pelanggan. Baik respons buat maupun respons pembaruan tidak menggemakan bidang kembali, jadi konfirmasikan nilai yang disimpan denganDescribeSubscriber, 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. INFOmencatat 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 LevelINFO, atau ERROR_LOGS untuk LevelERROR.
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-arndestination-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_typeadalah EVENT_DELIVERY_ATTEMPT untuk upaya pengiriman; jenis lainnya tercantum di awal bagian ini. resource_arnadalah ARN pelanggan yang melakukan upaya, yang merupakan cara Anda memisahkan pelanggan yang berbagi satu grup log. log_leveladalah tingkat catatan itu sendiri: upaya yang berhasilINFO, dan upaya yang gagal adalahERROR, itulah sebabnya Level ERROR masih mencatat kegagalan. detailsadalah objek yang memegang status pengiriman, dan menyimpan bidang tempat Anda membuat kueri dan alarm.
outcomedanattempt_count-
SUCCESSatauFAILUREuntuk 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, atauEVENTS_DROPPEDketika percobaan ulang habis dan tidak ada tujuan pada kegagalan yang dikonfigurasi. target_arndantarget_properties-
Target yang dilakukan oleh upaya tersebut, dan parameter target yang diselesaikan pelanggan untuk acara ini.
target_propertiesdihilangkan ketika pelanggan tidak mengonfigurasi parameter. ingestion_to_start_latency_msdaningestion_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; lihatMuatan dalam catatan log.
event_detail,event_metadata, danevent_system_metadata-
Acara seperti yang EventBridge diadakan.
event_system_metadatamembawa pengidentifikasi yang Anda gunakan untuk menghubungkan catatan.event_detailmuncul hanya ketika berbeda daritarget_input, yang merupakan kasus ketika pelanggan memiliki transformator.
Untuk mendiagnosis pengiriman yang tidak pernah tiba, baca catatan pelanggan dalam urutan ini. outcomemengatakan apakah EventBridge mencapai target sama sekali. attempt_countmengatakan apakah masih mencoba lagi, karena acara tanpa terminal_kind catatan belum selesai. terminal_kindmengatakan 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.
Muatan dalam catatan log
IncludePayloadmengontrol dua bidang dan tidak ada yang lain: details.target_input dandetails.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. FULLmenyematkan 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. DenganFULL, 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 keON_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, lihatLogging panggilan Amazon EventBridge API menggunakan AWS CloudTrail.
