Bagikan melalui

Pengiriman dan coba lagi pesan Azure Event Grid

  • Artikel

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 ke 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 mati akan dihilangkan ketika tujuan surat mati tidak ditemukan.

Jika kesalahan yang dikembalikan oleh titik akhir berlangganan bukan di antara 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.

Event Grid menambahkan pengacakan kecil ke semua langkah coba lagi dan mungkin secara oportunistik melewati percobaan ulang tertentu jika titik akhir secara konsisten tidak sehat, turun untuk jangka waktu yang lama, atau tampaknya 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. Ketika peristiwa tidak dikirimkan setelah 30 menit (atau) tidak dikirimkan setelah 5 upaya, mana pun yang terjadi terlebih dahulu, peristiwa akan dihentikan. 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 ke 10 tidak akan berdampak dalam hal ini dan peristiwa akan di-dead-letter setelah 30 menit.

Pembuatan batch output

Azure Event Grid default mengirimkan setiap acara satu per satu ke pelanggan. Pelanggan menerima larik dengan satu acara. Anda dapat mengonfigurasi Event Grid ke peristiwa 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 maks per batch - Jumlah maksimum peristiwa yang dikirimkan Event Grid per batch. Jumlah ini tidak akan pernah terlampaui, namun lebih sedikit peristiwa yang mungkin dikirimkan jika tidak ada peristiwa lain yang tersedia pada saat penerbitan. 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 peristiwa maks, ukuran batch mungkin lebih kecil jika lebih banyak peristiwa tidak tersedia pada saat penerbitan. 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 mungkin per batch karena dapat ditangani 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 Azure:

Anda melihat pengaturan ini pada tab Fitur Tambahan di halaman Langganan Peristiwa.

Cuplikan layar menabur tab Fitur Tambahan dari halaman Langganan Peristiwa dengan bagian Batching disorot.

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 selama 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.
Penuh 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.
Canceled 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 dihentikan atau dihilangkan tanpa mencoba pengiriman tergantung pada kode kesalahan karena sedang dalam masa percobaan.

Kesalahan Durasi Masa Percobaan
Sibuk 10 detik
NotFound 5 menit
SocketError 30 detik
ResolutionError 5 menit
Nonaktif 5 menit
Penuh 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 dalam set (200-204) dianggap gagal dan akan dicoba kembali (jika diperlukan). Beberapa memiliki kebijakan percobaan kembali khusus yang terkait dengan kebijakan yang diuraikan di sini, 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 Perilaku percobaan kembali
400 Permintaan Buruk Tidak dicoba
401 Tidak Sah Percobaan ulang setelah 5 menit atau lebih untuk Titik Akhir Sumber Daya Azure
403 Dilarang 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
Entitas Permintaan 413 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