Pengiriman dan coba lagi pesan Azure Event Grid
Azure Event Grid menyediakan pengiriman yang tahan lama. Event Grid mencoba untuk dengan segera mengirimkan setiap pesan setidaknya satu kali untuk setiap langganan yang cocok. Jika titik akhir pelanggan tidak mengakui penerimaan suatu peristiwa atau jika terjadi kegagalan, Event Grid mencoba lagi pengiriman berdasarkan jadwal coba lagi dan kebijakan coba lagi yang ditetapkan. Secara default, Event Grid mengirimkan satu per satu acara kepada pelanggan. Namun, payload adalah array dengan satu peristiwa.
Catatan
Event Grid tidak menjamin susunan untuk pengiriman acara, jadi pelanggan mungkin menerimanya tidak sesuai susunan.
Jadwal percobaan kembali
Saat Event Grid menerima kesalahan untuk upaya pengiriman peristiwa, Event Grid memutuskan apakah harus mencoba lagi pengiriman, mematikan peristiwa, atau membatalkan peristiwa berdasarkan jenis kesalahan.
Jika kesalahan yang ditampilkan oleh titik akhir langganan adalah kesalahan terkait konfigurasi yang tidak dapat diperbaiki dengan percobaan ulang (misalnya, jika titik akhir dihapus), Event Grid akan melakukan dead-lettering pada peristiwa atau membatalkan peristiwa jika dead-lettering belum dikonfigurasi.
Tabel berikut menjelaskan jenis titik akhir dan kesalahan yang tidak dapat diatasi dengan percobaan ulang:
| Jenis Titik Akhir | Kode kesalahan |
|---|---|
| Sumber Daya Azure | 400 (Permintaan buruk), 413 (Entitas permintaan terlalu besar) |
| Webhook | 400 (Permintaan buruk), 413 (Entitas permintaan terlalu besar), 401 (Tidak sah) |
Catatan
Jika surat gagal tidak dikonfigurasi untuk titik akhir, acara akan dihapus ketika kesalahan di atas terjadi. Pertimbangkan untuk mengonfigurasi Surat Gagal jika Anda tidak ingin acara semacam ini dihapus. Peristiwa surat gagal akan dihilangkan ketika tujuan surat gagal tidak ditemukan.
Jika kesalahan yang dikembalikan oleh titik akhir langganan tidak termasuk dalam daftar di atas, Event Grid melakukan coba lagi menggunakan kebijakan yang dijelaskan di bawah ini:
Azure Event Grid menunggu respons selama 30 detik setelah mengirim pesan. Setelah 30 detik, jika titik akhir belum merespons, pesan akan diantrekan untuk dicoba lagi. Azure Event Grid menggunakan kebijakan coba lagi backoff eksponensial untuk pengiriman acara. Azure Event Grid mencoba lagi pengiriman pada jadwal berikut dengan upaya terbaik:
- 10 detik
- 30 detik
- 1 menit
- 5 menit
- 10 menit
- 30 menit
- 1 jam
- 3 jam
- 6 jam
- Setiap 12 jam hingga 24 jam
Jika titik akhir merespons dalam waktu 3 menit, Event Grid mencoba menghapus peristiwa dari antrean coba lagi berdasarkan upaya terbaik, tetapi duplikat mungkin masih diterima.
Azure Event Grid menambahkan pengacakan kecil untuk semua langkah coba lagi dan mungkin secara oportunis melewatkan percobaan ulang tertentu jika titik akhir secara konsisten tidak sehat, tidak berfungsi untuk waktu yang lama, atau tampak kewalahan.
Kebijakan percobaan kembali
Anda dapat mengkustomisasi kebijakan percobaan kembali saat membuat langganan acara dengan menggunakan dua konfigurasi berikut. Peristiwa akan dihilangkan jika salah satu batas kebijakan percobaan ulang tercapai.
- Jumlah maksimum upaya - Nilai harus berupa integer antara 1 dan 30. Nilai default adalah 30.
- Event time-to-live (TTL) - Nilai harus berupa bilangan bulat antara 1 dan 1440. Nilai defaultnya adalah 1440 menit
Untuk contoh perintah CLI dan PowerShell untuk mengonfigurasi pengaturan ini, lihat Mengatur kebijakan percobaan kembali.
Catatan
Jika Anda mengatur Event time to live (TTL) dan Maximum number of attempts, Event Grid menggunakan yang pertama yang kedaluwarsa guna menentukan kapan harus menghentikan pengiriman peristiwa. Misalnya, jika Anda menetapkan 30 menit sebagai time-to-live (TTL) dan 5 upaya pengiriman maks. Saat peristiwa tidak dikirimkan setelah 30 menit (atau) tidak dikirimkan setelah 5 upaya, mana pun yang terjadi terlebih dahulu, peristiwa tersebut akan di-dead-letter. Jika Anda menetapkan upaya pengiriman maks ke 10, sehubungan dengan jadwal coba lagi eksponensial, maksimal 6 jumlah upaya pengiriman terjadi sebelum 30 menit TTL akan tercapai, oleh karena itu menetapkan jumlah maksimum upaya menjadi 10 tidak akan berdampak dalam kasus ini dan peristiwa akan dikirim melalui surat gagal setelah 30 menit.
Batch output
Azure Event Grid default mengirimkan setiap acara satu per satu ke pelanggan. Pelanggan menerima larik dengan satu acara. Anda dapat mengonfigurasi Azure Event Grid ke acara batch untuk pengiriman guna meningkatkan performa HTTP dalam skenario throughput tinggi. Batching dimatikan secara default dan dapat diaktifkan per langganan.
Kebijakan batching
Pengiriman dalam batch memiliki dua pengaturan:
- Peristiwa maksimum per batch - Jumlah maksimum peristiwa yang dikirimkan Event Grid per batch. Jumlah ini tidak akan pernah terlampaui, tetapi lebih sedikit acara yang mungkin dikirimkan jika tidak ada acara lain yang tersedia pada saat publikasi. Azure Event Grid tidak menunda acara untuk membuat batch jika lebih sedikit acara yang tersedia. Harus antara 1 hingga 5.000.
- Ukuran batch pilihan dalam kilobyte - Ceiling target untuk ukuran batch dalam kilobyte. Mirip dengan acara maksimal, ukuran batch mungkin lebih kecil jika lebih banyak acara tidak tersedia pada saat publikasi. Ada kemungkinan bahwa batch lebih besar dari ukuran batch pilihan jika suatu acara lebih besar dari ukuran pilihan. Misalnya, jika ukuran pilihan adalah 4 KB dan acara 10-KB dikirim ke Azure Event Grid, acara10-KB tersebut akan tetap dikirimkan dalam batch-nya sendiri, bukan dibuang.
Pengiriman dalam batch dikonfigurasi berdasarkan langganan per acara melalui portal, CLI, PowerShell, atau SDK.
Perilaku batching
Semua atau tidak ada
Event Grid beroperasi dengan semantik semua atau tidak ada. Ini tidak mendukung keberhasilan parsial dari pengiriman batch. Pelanggan harus berhati-hati untuk hanya meminta peristiwa sebanyak per batch karena mereka dapat menangani secara wajar dalam 30 detik.
Batching optimis
Pengaturan kebijakan batching tidak terikat ketat pada perilaku batching, dan dihormati berdasarkan upaya terbaik. Pada tingkat peristiwa rendah, Anda akan sering mengamati ukuran batch yang kurang dari peristiwa maksimum yang diminta per batch.
Asali disetel ke NONAKTIF
Secara default, Event Grid hanya menambahkan satu peristiwa ke setiap permintaan pengiriman. Cara mengaktifkan batching adalah dengan mengatur salah satu pengaturan yang disebutkan sebelumnya dalam artikel di langganan JSON.
Nilai default
Tidak perlu menentukan pengaturan (Peristiwa maksimum per batch dan Perkiraan ukuran batch dalam kilo byte) saat membuat langganan acara. Jika hanya satu pengaturan yang diatur, Azure Event Grid menggunakan nilai default (dapat dikonfigurasi). Lihat bagian berikut untuk nilai default, dan cara menggantinya.
portal Microsoft Azure:
Anda melihat pengaturan ini pada tab Fitur Tambahan di halaman Langganan Peristiwa .
Azure CLI
Saat membuat langganan acara, gunakan parameter berikut:
- max-events-per-batch - Jumlah peristiwa maksimum dalam satu batch. Harus berupa angka antara 1 hingga 5000.
- preferred-batch-size-in-kilobyte - Ukuran batch pilihan dalam kilobyte. Harus berupa angka antara 1 hingga 1024.
storageid=$(az storage account show --name <storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
endpoint=https://$sitename.azurewebsites.net/api/updates
az eventgrid event-subscription create \
--resource-id $storageid \
--name <event_subscription_name> \
--endpoint $endpoint \
--max-events-per-batch 1000 \
--preferred-batch-size-in-kilobytes 512
Untuk informasi selengkapnya tentang menggunakan Azure CLI dengan Azure Event Grid, lihat Merutekan kejadian penyimpanan ke titik akhir web dengan Azure CLI.
Pengiriman Tertunda
Saat titik akhir mengalami kegagalan pengiriman, Event Grid mulai menunda pengiriman dan mencoba kembali peristiwa ke titik akhir tersebut. Misalnya, jika 10 peristiwa pertama yang diterbitkan ke titik akhir gagal, Event Grid mengasumsikan bahwa titik akhir mengalami masalah dan akan menunda semua percobaan ulang berikutnya dan pengiriman baru untuk beberapa waktu - dalam beberapa kasus hingga beberapa jam.
Tujuan fungsional penundaan pengiriman adalah untuk melindungi titik akhir yang tidak sehat dan sistem Azure Event Grid. Tanpa back-off dan penundaan pengiriman ke titik akhir yang tidak sehat, kebijakan dan kemampuan volume Azure Event Grid dapat membanjiri sistem dengan mudah.
Kejadian Surat gagal
Saat Azure Event Grid tidak dapat mengirimkan acara dalam periode waktu tertentu atau setelah mencoba mengirimkan acara beberapa kali, Azure Event Grid tersebut dapat mengirimkan acara yang tidak terkirim ke akun penyimpanan. Proses ini dikenal sebagai surat gagal. Azure Event Grid melakukan surat gagal pada suatu acara ketika salah satu kondisi berikut terpenuhi.
- Acara tidak dikirimkan dalam periode time-to-live.
- Jumlah percobaan untuk mengirimkan acara telah melebihi batas.
Jika salah satu kondisi terpenuhi, acara akan dihapus atau disurat-gagalkan. Secara default, Azure Event Grid tidak mengaktifkan surat gagal. Untuk mengaktifkannya, Anda harus menentukan akun penyimpanan untuk menyimpan acara yang tidak terkirim saat membuat langganan acara. Anda menarik acara dari akun penyimpanan ini untuk menyelesaikan pengiriman.
Azure Event Grid mengirimkan acara ke lokasi surat gagal ketika telah mencoba semua upaya coba lagi. Jika Azure Event Grid menerima kode respons 400 (Permintaan Buruk) atau 413 (Meminta Entitas yang Terlalu Besar), Azure Event Grid tersebut akan segera menjadwalkan acara untuk surat gagal. Kode respons ini menunjukkan pengiriman acara tidak akan pernah berhasil.
Kedaluwarsa time-to-live HANYA dicentang pada pengiriman terjadwal berikutnya. Jadi, bahkan jika time-to-live kedaluwarsa sebelum upaya pengiriman terjadwal berikutnya, kedaluwarsa acara hanya dicentang pada saat pengiriman berikutnya dan kemudian disurat-gagalkan.
Ada penundaan lima menit antara upaya terakhir untuk menyampaikan suatu peristiwa dan saat peristiwa dikirim ke lokasi dead-letter. Penundaan ini dimaksudkan untuk mengurangi jumlah operasi penyimpanan Blob. Jika lokasi surat gagal tidak tersedia selama empat jam, acara akan dihapuskan.
Sebelum mengatur lokasi surat gagal, Anda harus memiliki akun penyimpanan dengan kontainer. Anda memberikan titik akhir untuk kontainer ini saat membuat langganan acara. Titik akhir tersebut menggunakan format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>
Anda mungkin ingin diberitahu ketika sebuah acara telah dikirim ke lokasi surat gagal. Untuk menggunakan Azure Event Grid guna merespons acara yang terkirim, buat langganan acara untuk penyimpanan blob surat gagal. Setiap kali penyimpanan blob surat gagal menerima acara yang tidak terkirim, Azure Event Grid memberi tahu penghandel Anda. Penghandel merespons dengan tindakan yang ingin Anda lakukan untuk menyesuaikan acara yang tidak terkirim. Untuk contoh pengaturan kebijakan lokasi surat gagal dan coba lagi, lihat Kebijakan surat gagal dan coba lagi.
Catatan
Jika Anda mengaktifkan identitas terkelola untuk surat gagal, Anda harus menambahkan identitas terkelola ke peran kontrol akses berbasis peran (RBAC) yang sesuai di akun Azure Storage yang akan menyimpan peristiwa surat gagal. Untuk informasi selengkapnya, lihat Tujuan yang didukung dan peran Azure.
Format pengiriman acara
Bagian ini memberikan contoh acara dan kejadian surat gagal dalam format skema pengiriman yang berbeda (skema Azure Event Grid, skema CloudEvents 1.0, dan skema kustom). Untuk informasi selengkapnya tentang format tersebut, lihat skema Azure Event Grid dan artikel skema Cloud Events 1.0.
Skema Azure Event Grid
Kejadian
{
"id": "93902694-901e-008f-6f95-7153a806873c",
"eventTime": "2020-08-13T17:18:13.1647262Z",
"eventType": "Microsoft.Storage.BlobCreated",
"dataVersion": "",
"metadataVersion": "1",
"topic": "/subscriptions/000000000-0000-0000-0000-00000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
"subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",
"data": {
"api": "PutBlob",
"clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
"requestId": "93902694-901e-008f-6f95-7153a8000000",
"eTag": "0x8D83FACDC0C3402",
"contentType": "text/plain",
"contentLength": 0,
"blobType": "BlockBlob",
"url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
"sequencer": "00000000000000000000000000015508000000000005101c",
"storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
}
}
Kejadian Surat gagal
{
"id": "93902694-901e-008f-6f95-7153a806873c",
"eventTime": "2020-08-13T17:18:13.1647262Z",
"eventType": "Microsoft.Storage.BlobCreated",
"dataVersion": "",
"metadataVersion": "1",
"topic": "/subscriptions/0000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
"subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",
"data": {
"api": "PutBlob",
"clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
"requestId": "93902694-901e-008f-6f95-7153a8000000",
"eTag": "0x8D83FACDC0C3402",
"contentType": "text/plain",
"contentLength": 0,
"blobType": "BlockBlob",
"url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
"sequencer": "00000000000000000000000000015508000000000005101c",
"storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
},
"deadLetterReason": "MaxDeliveryAttemptsExceeded",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "NotFound",
"publishTime": "2020-08-13T17:18:14.0265758Z",
"lastDeliveryAttemptTime": "2020-08-13T17:18:14.0465788Z"
}
Berikut adalah kemungkinan nilai lastDeliveryOutcome dan deskripsinya.
| LastDeliveryOutcome | Deskripsi |
|---|---|
| NotFound | Sumber daya tujuan tidak ditemukan. |
| Nonaktif | Tujuan telah menonaktifkan peristiwa penerimaan. Berlaku untuk Azure Service Bus dan Azure Event Hubs. |
| Data | Melebihi jumlah maksimum operasi yang diizinkan di tujuan. Berlaku untuk Azure Service Bus dan Azure Event Hubs. |
| Tidak diizinkan | Tujuan menampilkan kode respons yang tidak sah. |
| BadRequest | Tujuan menampilkan kode respons permintaan yang buruk. |
| TimedOut | Waktu operasi pengiriman habis. |
| Sibuk | Server tujuan sibuk. |
| PayloadTooLarge | Ukuran pesan melebihi ukuran maksimum yang diizinkan oleh tujuan. Berlaku untuk Azure Service Bus dan Azure Event Hubs. |
| Masa percobaan | Tujuan dimasukkan ke dalam masa percobaan oleh Event Grid. Pengiriman tidak dicoba selama masa percobaan. |
| Batal | Operasi pengiriman dibatalkan. |
| Gagal | Pengiriman dibatalkan oleh Event Grid setelah interval waktu. |
| SocketError | Terjadi kesalahan komunikasi jaringan selama pengiriman. |
| ResolutionError | Resolusi DNS titik akhir tujuan gagal. |
| Mengirimkan | Menyampaikan peristiwa ke tempat tujuan. |
| SessionQueueNotSupported | Pengiriman peristiwa tanpa ID sesi dicoba pada entitas, yang memiliki dukungan sesi yang diaktifkan. Berlaku untuk tujuan entitas Azure Service Bus. |
| Terlarang | Pengiriman dilarang oleh titik akhir tujuan (bisa karena firewall IP atau batasan lainnya) |
| InvalidAzureFunctionDestination | Fungsi Azure tujuan tidak valid. Mungkin karena tidak memiliki jenis EventGridTrigger. |
LastDeliveryOutcome: Masa Percobaan
Langganan peristiwa dimasukkan ke dalam masa percobaan selama durasi oleh Event Grid jika pengiriman peristiwa ke tujuan tersebut mulai gagal. Waktu percobaan berbeda untuk kesalahan lain yang ditampilkan oleh titik akhir tujuan. Jika langganan peristiwa sedang dalam masa percobaan, peristiwa mungkin akan gagal atau dibatalkan bahkan tanpa mencoba pengiriman, bergantung pada kode kesalahan yang menyebabkannya dalam masa percobaan.
| Kesalahan | Durasi Masa Percobaan |
|---|---|
| Sibuk | 10 detik |
| NotFound | 5 menit |
| SocketError | 30 detik |
| ResolutionError | 5 menit |
| Nonaktif | 5 menit |
| Data | 5 menit |
| TimedOut | 10 detik |
| Tidak diizinkan | 5 menit |
| Terlarang | 5 menit |
| InvalidAzureFunctionDestination | 10 menit |
Catatan
Event Grid menggunakan masa percobaan untuk manajemen pengiriman yang lebih baik dan durasinya mungkin dapat berubah di masa mendatang.
Skema CloudEvents 1.0
Kejadian
{
"id": "caee971c-3ca0-4254-8f99-1395b394588e",
"source": "mysource",
"dataversion": "1.0",
"subject": "mySubject",
"type": "fooEventType",
"datacontenttype": "application/json",
"data": {
"prop1": "value1",
"prop2": 5
}
}
Kejadian Surat gagal
{
"id": "caee971c-3ca0-4254-8f99-1395b394588e",
"source": "mysource",
"dataversion": "1.0",
"subject": "mySubject",
"type": "fooEventType",
"datacontenttype": "application/json",
"data": {
"prop1": "value1",
"prop2": 5
},
"deadletterreason": "MaxDeliveryAttemptsExceeded",
"deliveryattempts": 1,
"lastdeliveryoutcome": "NotFound",
"publishtime": "2020-08-13T21:21:36.4018726Z",
}
Skema kustom
Kejadian
{
"prop1": "my property",
"prop2": 5,
"myEventType": "fooEventType"
}
Kejadian Surat gagal
{
"id": "8bc07e6f-0885-4729-90e4-7c3f052bd754",
"eventTime": "2020-08-13T18:11:29.4121391Z",
"eventType": "myEventType",
"dataVersion": "1.0",
"metadataVersion": "1",
"topic": "/subscriptions/00000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.EventGrid/topics/myCustomSchemaTopic",
"subject": "subjectDefault",
"deadLetterReason": "MaxDeliveryAttemptsExceeded",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "NotFound",
"publishTime": "2020-08-13T18:11:29.4121391Z",
"lastDeliveryAttemptTime": "2020-08-13T18:11:29.4277644Z",
"data": {
"prop1": "my property",
"prop2": 5,
"myEventType": "fooEventType"
}
}
Status pengiriman pesan
Event Grid menggunakan kode respons HTTP untuk menyetujui penerimaan acara.
Kode keberhasilan
Azure Event Grid hanya mempertimbangkan kode respons HTTP berikut sebagai pengiriman yang berhasil. Semua kode status lainnya dianggap sebagai pengiriman yang gagal dan akan dicoba atau digagalkan sebagaimana mestinya. Saat menerima kode status yang berhasil, Event Grid menganggap pengiriman selesai.
- 200 OK
- 201 Dibuat
- 202 Diterima
- 203 Informasi Non-Otoritatif
- 204 Tidak Ada Konten
Kode kegagalan
Semua kode lain yang tidak ada pada set di atas (200-204) dianggap gagal dan akan dicoba lagi (jika perlu). Beberapa memiliki kebijakan coba lagi khusus yang terkait dengan kebijakan yang diuraikan di bawah ini, yang lain mengikuti model back-off eksponensial standar. Penting untuk diingat bahwa karena sifat arsitektur Azure Event Grid yang sangat paralel, perilaku percobaan ulang bersifat non-deterministik.
| Kode status | Coba lagi perilaku |
|---|---|
| 400 Permintaan Buruk | Tidak dicoba |
| 401 Tidak Sah | Percobaan ulang setelah 5 menit atau lebih untuk Titik Akhir Sumber Daya Azure |
| 403 Terlarang | Tidak dicoba |
| 404 Tidak Ditemukan | Percobaan ulang setelah 5 menit atau lebih untuk Titik Akhir Sumber Daya Azure |
| 408 Waktu Permintaan Habis | Percobaan ulang setelah 2 menit atau lebih |
| 413 Meminta Entitas yang Terlalu Besar | Tidak dicoba |
| 503 Layanan Tidak Tersedia | Percobaan ulang setelah 30 detik atau lebih |
| Semua lainnya | Percobaan ulang setelah 10 detik atau lebih |
Properti pengiriman kustom
Langganan kejadian memungkinkan Anda menyiapkan header HTTP yang disertakan dalam kejadian terkikis. Kapabilitas ini memungkinkan Anda untuk mengatur header kustom yang diperlukan oleh tujuan. Anda bisa menyiapkan hingga 10 header saat membuat langganan kejadian. Setiap nilai header tidak boleh lebih besar dari 4.096 (4K) byte. Anda bisa mengatur header kustom pada kejadian yang dikirimkan ke tujuan berikut:
- Webhook
- Topik dan antrean Azure Service Bus
- Azure Event Hubs
- Penyampaian Koneksi Hibrid
Untuk informasi selengkapnya, lihat Properti pengiriman kustom.
Langkah berikutnya
- Untuk melihat status pengiriman acara, lihat Memantau pengiriman pesan Azure Event Grid.
- Untuk menyesuaikan opsi pengiriman acara, lihat Kebijakan surat gagal dan coba lagi.