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. 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:

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 sumber Amazon SQS, EventBridge Pipes tidak menghitung percobaan ulang untuk kesalahan internal terhadap jumlah penerimaan maksimum untuk sumber Amazon SQS.

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:

Untuk kesalahan pemanggilan pelanggan, EventBridge Pipes melakukan hal berikut:

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, Pipes mendukung penanganan kegagalan batch sebagian dari EventBridge kegagalan target. Untuk informasi selengkapnya, lihat Kegagalan batch sebagian.

Waktu coba lagi sumber Amazon SQS dengan maxBatchWindow InSeconds

Saat menggunakan antrean Amazon SQS sebagai sumber pipa, perilaku waktu coba lagi berbeda tergantung pada apakah Anda mengonfigurasi parameter: maxBatchWindowInSeconds

Perilaku ini sangat relevan saat menggunakan respons batch sebagian. Jika Anda memerlukan waktu coba ulang yang lebih cepat, hindari pengaturan maxBatchWindowInSeconds dan sebagai gantinya mengandalkan batas waktu visibilitas antrian yang dikonfigurasi.

Perilaku pipa DLQ

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

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 sumbernya MaximumRecordAge sehingga ada waktu yang cukup antara saat acara dikirim ke DLQ, dan kapan itu dihapus secara otomatis oleh sumber bagi Anda untuk menentukan mengapa acara tersebut masuk ke DLQ.

MaximumRecordAgeInSecondsParameter berlaku secara independen dari perilaku coba lagi. Saat melakukan polling sumber aliran, jika usia rekaman melebihi MaximumRecordAgeInSeconds nilainya, EventBridge Pipes tidak akan memproses catatan itu, terlepas dari apakah ada situasi percobaan ulang. Catatan ini dikirim langsung ke DLQ (jika dikonfigurasi) tanpa upaya pemrosesan apa pun.

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 DLQ untuk aliran MSK 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:

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 AWS KMS kunci yang AWS dikelola, Anda harus secara eksplisit memberikan izin dekripsi Peran Eksekusi pipa Anda. Untuk melakukannya, sertakan izin tambahan berikut dalam kebijakan CMK 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 Pipa Anda.

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