Penanganan kesalahan dan pemecahan masalah Amazon EventBridge Pipes - Amazon EventBridge

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Penanganan kesalahan dan pemecahan masalah Amazon EventBridge Pipes

Memahami jenis kesalahan yang mungkin dihadapi EventBridge Pipa, dan bagaimana EventBridge menangani kesalahan tersebut, dapat membantu Anda memecahkan masalah dengan pipa Anda.

Coba lagi perilaku dan penanganan kesalahan

EventBridge Pipa secara otomatis mencoba ulang pengayaan dan target pemanggilan pada setiap AWS kegagalan yang dapat dicoba kembali dengan layanan sumber, pengayaan atau layanan target, atau. EventBridge Namun, jika ada kegagalan yang dikembalikan oleh pengayaan atau implementasi target pelanggan, throughput pemungutan suara pipa secara bertahap akan mundur. Untuk kesalahan 4xx yang hampir terus menerus (seperti masalah otorisasi dengan IAM atau sumber daya yang hilang), pipa dapat dinonaktifkan secara otomatis dengan pesan penjelasan di file. StateReason

Kesalahan pemanggilan pipa dan perilaku coba lagi

Saat Anda memanggil pipa, dua jenis kesalahan utama dapat terjadi: kesalahan internal pipa dan kesalahan pemanggilan pelanggan.

Kesalahan internal pipa

Kesalahan internal pipa adalah kesalahan yang dihasilkan oleh aspek pemanggilan yang dikelola oleh layanan EventBridge Pipa.

Jenis kesalahan ini dapat mencakup masalah seperti:

  • Kegagalan HTTP koneksi saat mencoba memanggil layanan targer pelanggan

  • Penurunan ketersediaan sementara pada layanan pipa itu sendiri.

Secara umum, EventBridge Pipes mencoba ulang kesalahan internal dalam jumlah yang tidak terbatas, dan berhenti hanya ketika catatan kedaluwarsa di sumbernya.

Untuk pipa dengan sumber aliran, EventBridge Pipa tidak menghitung percobaan ulang untuk kesalahan internal terhadap jumlah maksimum percobaan ulang yang ditentukan pada kebijakan coba lagi untuk sumber aliran. Untuk pipa dengan SQS sumber Amazon, EventBridge Pipes tidak menghitung percobaan ulang untuk kesalahan internal terhadap jumlah penerimaan maksimum untuk SQS sumber Amazon.

Kesalahan pemanggilan pelanggan

Kesalahan pemanggilan pelanggan adalah kesalahan yang dihasilkan dari konfigurasi atau kode yang dikelola oleh pengguna.

Jenis kesalahan ini dapat mencakup masalah seperti:

  • Izin yang tidak memadai pada pipa untuk memanggil target.

  • Kesalahan logika di Lambda, Step Functions, tujuan, atau titik akhir Gateway pelanggan yang dipanggil secara sinkron. API API

Untuk kesalahan pemanggilan pelanggan, EventBridge Pipes melakukan hal berikut:

  • Untuk pipa dengan sumber aliran, EventBridge Pipes mencoba ulang hingga waktu percobaan ulang maksimum yang dikonfigurasi pada kebijakan coba lagi pipa atau sampai usia rekor maksimum berakhir, mana yang lebih dulu.

  • Untuk pipa dengan SQS sumber Amazon, EventBridge Pipes mencoba ulang kesalahan pelanggan hingga jumlah penerimaan maksimum pada antrian sumber.

  • Untuk pipa dengan sumber Apache Kafka atau Amazon MQ EventBridge , coba lagi kesalahan pelanggan sama seperti mencoba ulang kesalahan internal.

Untuk pipa dengan target komputasi, Anda harus memanggil pipa secara serempak agar EventBridge Pipes mengetahui kesalahan runtime yang dilemparkan dari logika komputasi pelanggan dan mencoba lagi kesalahan tersebut. Pipa tidak dapat mencoba lagi kesalahan yang dilemparkan dari logika alur kerja standar Step Functions, karena target ini harus dipanggil secara asinkron.

Untuk Amazon SQS dan sumber aliran, seperti Kinesis dan DynamoDB, EventBridge Pipes mendukung penanganan kegagalan batch sebagian dari kegagalan target. Untuk informasi selengkapnya, lihat Kegagalan batch sebagian.

DLQPerilaku pipa

Pipa mewarisi perilaku antrian huruf mati (DLQ) dari sumbernya:

  • Jika SQS antrian Amazon sumber telah dikonfigurasiDLQ, pesan secara otomatis dikirim ke sana setelah jumlah upaya yang ditentukan.

  • Untuk sumber aliran, seperti aliran DynamoDB dan Kinesis, Anda dapat DLQ mengonfigurasi peristiwa untuk pipa dan rute. Sumber aliran DynamoDB dan Kinesis mendukung antrian SNS Amazon dan SQS topik Amazon sebagai target. DLQ

Jika Anda menentukan DeadLetterConfig untuk pipa dengan sumber Kinesis atau DynamoDB, pastikan bahwa MaximumRecordAgeInSeconds properti pada pipa kurang dari peristiwa sumber. MaximumRecordAge MaximumRecordAgeInSecondsmengontrol kapan poller pipa akan menyerah pada acara tersebut dan mengirimkannya ke DLQ dan MaximumRecordAge mengontrol berapa lama pesan akan terlihat di aliran sumber sebelum dihapus. Oleh karena itu, atur MaximumRecordAgeInSeconds ke nilai yang kurang dari sumber MaximumRecordAge sehingga ada waktu yang cukup antara saat acara dikirim keDLQ, dan ketika itu akan dihapus secara otomatis oleh sumber bagi Anda untuk menentukan mengapa acara tersebut pergi keDLQ.

Untuk sumber Amazon MQ, DLQ dapat dikonfigurasi langsung di broker pesan.

EventBridge Pipa tidak mendukung first-in first-out (FIFO) DLQs untuk sumber aliran.

EventBridge Pipes tidak mendukung MSK aliran DLQ Amazon dan sumber aliran Apache Kafka yang dikelola sendiri.

Status kegagalan pipa

Membuat, menghapus, dan memperbarui pipa adalah operasi asinkron yang dapat mengakibatkan status kegagalan. Demikian juga, pipa mungkin dinonaktifkan secara otomatis karena kegagalan. Dalam semua kasus, pipa StateReason memberikan informasi untuk membantu memecahkan masalah kegagalan.

Berikut ini adalah contoh dari StateReason nilai yang mungkin:

  • Stream tidak ditemukan. Untuk melanjutkan pemrosesan, hapus pipa dan buat yang baru.

  • Pipa tidak memiliki izin yang diperlukan untuk melakukan operasi Antrian (sqs:ReceiveMessage, sqs: dan sqs:DeleteMessage ) GetQueueAttributes

  • Kesalahan koneksi. Anda VPC harus dapat terhubung ke pipa. Anda dapat memberikan akses dengan mengonfigurasi NAT Gateway atau VPC Endpoint ke pipes-data. Untuk cara mengatur NAT gateway atau VPC Endpoint ke pipes-data, silakan periksa dokumentasi. AWS

  • MSKcluster tidak memiliki grup keamanan yang terkait dengannya

Pipa dapat dihentikan secara otomatis dengan pembaruanStateReason. Alasan yang mungkin termasuk:

Kegagalan enkripsi khusus

Jika Anda mengonfigurasi sumber untuk menggunakan kunci enkripsi AWS KMS kustom (CMK), bukan kunci AWS-managed AWS KMS , Anda harus secara eksplisit memberikan izin dekripsi Peran Eksekusi pipa Anda. Untuk melakukannya, sertakan izin tambahan berikut dalam CMK kebijakan khusus:

{ "Sid": "Allow Pipes access", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::01234567890:role/service-role/Amazon_EventBridge_Pipe_DDBStreamSourcePipe_12345678" }, "Action": "kms:Decrypt", "Resource": "*" }

Ganti peran di atas dengan Peran Eksekusi pipa Anda.

Selanjutnya, pastikan bahwa izin yang sama untuk KMS ditambahkan ke peran eksekusi Pipe Anda.

Hal ini berlaku untuk semua sumber pipa dengan AWS KMS CMK, termasuk:

  • Amazon DynamoDB Streams

  • Amazon Kinesis Data Streams

  • Amazon MQ

  • Amazon MSK

  • Amazon SQS