Mencoba kembali peristiwa

Acara dapat ditolak karena beberapa alasan. Misalnya, layanan penerima peristiwa mungkin tidak tersedia untuk sementara karena gangguan; error mungkin terjadi pada layanan saat memproses peristiwa; atau resource layanan mungkin habis. Error sementara seperti ini dapat dicoba lagi.

Acara juga dapat gagal dikirim ke penerima acara. Misalnya, peristiwa mungkin tidak cocok dengan skema yang diharapkan yang dikonfigurasi, atau mediasi peristiwa mungkin gagal sebelum pesan peristiwa dapat dirutekan ke tujuan akhirnya. Kasus seperti itu akan menyebabkan error persisten.

Error sementara

Eventarc Advanced memberi Anda kemampuan untuk menangani error sementara. Error sementara ini dapat dicoba lagi dan mencakup error dengan kode error berikut:

• HTTP 408 Request Timeout
• HTTP 409 Conflict
• HTTP 429 Too Many Requests
• HTTP 500 Internal Server Error
• HTTP 502 Bad Gateway
• HTTP 503 Service Unavailable
• HTTP 504 Gateway Time-out

Error persisten

Berbeda dengan error sementara, error persisten mencakup hal berikut:

• Error yang terjadi saat jumlah percobaan ulang yang dikonfigurasi habis
• Error yang terjadi saat peristiwa gagal sebelum dapat dirutekan ke tujuannya
• Error yang menghasilkan kode error yang dianggap tidak dapat dicoba lagi; misalnya, kode error selain yang tercantum untuk error sementara

Anda dapat mengidentifikasi error persisten secara manual dan menanganinya dengan tepat.

Mencoba ulang error sementara

Eventarc Advanced menggunakan penundaan backoff eksponensial untuk menangani error yang dapat dicoba ulang. Kebijakan percobaan ulang default dimulai dengan penundaan satu detik, dan penundaan akan digandakan setelah setiap upaya gagal (hingga maksimum 60 detik dan lima upaya).

Anda dapat mengubah kebijakan percobaan ulang default menggunakan konsol Google Cloud atau perintah gcloud beta eventarc pipelines update.

Perhatikan bahwa faktor penundaan default 2 tidak dapat diubah.

gcloud beta eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

gcloud beta eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

Mengarsipkan pesan untuk menangani error persisten

Anda dapat menulis pesan ke tabel BigQuery saat pesan diterima. Dengan demikian, Anda dapat mengidentifikasi error persisten secara manual dan menanganinya dengan tepat.

Berikut ringkasan langkah-langkah yang diperlukan untuk mengarsipkan pesan acara, mengidentifikasi error persisten, dan mencoba lagi acara yang terpengaruh.

1. Buat bus. Konfigurasi bus dengan tepat; misalnya, untuk memublikasikan peristiwa dari sumber Google.
2. Buat topik Pub/Sub. Topik Pub/Sub ini akan menjadi tujuan target untuk pipeline Anda.
3. Buat langganan BigQuery untuk topik Pub/Sub. Langganan BigQuery adalah jenis langganan ekspor yang menulis pesan ke tabel BigQuery yang sudah ada saat pesan diterima. Atau, Anda dapat membuat tabel saat membuat langganan BigQuery.

4. Buat pipeline dan pendaftaran yang merutekan setiap pesan yang diterima oleh bus (menggunakan --cel-match="true") ke topik Pub/Sub. Konfigurasi kebijakan percobaan ulang untuk pipeline.

   Misalnya, perintah berikut membuat pipeline dan pendaftaran:

   gcloud beta eventarc pipelines create my-archive-pipeline \
       --destinations=pubsub_topic='my-archive-topic',network_attachment='my-network-attachment' \
       --min-retry-delay=1 \
       --max-retry-delay=20 \
       --max-retry-attempts=6 \
       --location=us-central1
   

   gcloud beta eventarc enrollments create my-archive-enrollment \
       --cel-match="true" \
       --destination-pipeline=my-archive-pipeline \
       --message-bus=my-message-bus \
       --message-bus-project=my-google-cloud-project \
       --location=us-central1
   

5. Arahkan log pipeline ke set data BigQuery lain.

   Sekarang Anda akan memiliki dua set data BigQuery terpisah: satu yang menyimpan setiap pesan yang diterima oleh bus Eventarc Advanced dan satu yang menyimpan log pipeline Anda.

6. Untuk mengidentifikasi pesan yang gagal, gunakan pernyataan kueri untuk menggabungkan kedua set data BigQuery pada kolom message_uid.

7. Setelah mengidentifikasi pesan yang gagal, Anda dapat memublikasikannya ke bus lagi menggunakan Eventarc Publishing API. Misalnya, Anda dapat men-deploy layanan atau tugas Cloud Run untuk membaca pesan dari BigQuery dan memublikasikannya secara langsung ke bus Eventarc Advanced.

Membuat pengendali peristiwa bersifat idempoten

Pengendali peristiwa yang dapat dicoba ulang harus bersifat idempoten, menggunakan panduan umum berikut:

• Banyak API eksternal yang dapat Anda gunakan untuk menyuplai kunci idempotensi sebagai parameter. Jika Anda menggunakan API seperti itu, Anda harus menggunakan sumber dan ID peristiwa sebagai kunci idempotensi. (Produsen harus memastikan bahwa source + id bersifat unik untuk setiap peristiwa yang berbeda.)
• Selain itu, Anda dapat menggunakan atribut CloudEvents, xgooglemessageuid, untuk menyediakan idempotensi. Nilai atribut ini sama dengan kolom message_uid di pesan Lanjutan Eventarc. Secara unik mengidentifikasi tindakan memublikasikan acara. Misalnya, jika peristiwa yang sama dipublikasikan dua kali ke bus, setiap peristiwa akan memiliki nilai xgooglemessageuid yang berbeda saat dikirim ke pengendali peristiwa.
• Idempotensi berfungsi dengan baik pada pengiriman "setidaknya sekali" karena memberikan keamanan untuk mencoba ulang. Jadi, salah satu praktik terbaik yang umum untuk menulis kode tepercaya adalah dengan menggabungkan idempotensi dengan percobaan ulang.
• Pastikan kode Anda idempoten secara internal. Contoh:
  • Pastikan mutasi bisa terjadi lebih dari sekali tanpa mengubah hasilnya.
  • Jalankan kueri pada status database dalam transaksi sebelum memutasikan status tersebut.
  • Pastikan semua efek samping bersifat idempoten.
• Lakukan pemeriksaan transaksi di luar layanan Anda, terlepas dari kode. Sebagai contoh, pertahankan status di suatu tempat yang mencatat bahwa ID peristiwa tertentu telah diproses.
• Tangani panggilan duplikat yang tidak umum. Misalnya, jalankan proses pembersihan terpisah yang akan melakukan pembersihan setelah panggilan duplikat.

Langkah berikutnya

• Memecahkan masalah
• Melihat log audit