Materi
Pesan yang selalu gagal diproses, misalnya karena datanya rusak, tidak boleh berputar di antrean selamanya dan menghalangi pesan lain. Azure Architecture Center menyebut tujuannya: antrean gagal (dead-letter queue, DLQ). Amazon SQS memakai maxReceiveCount, yaitu berapa kali sebuah pesan boleh diterima sebelum dipindahkan ke DLQ. Azure Service Bus menghitung jumlah pengiriman dan memindahkan pesan yang melewati batas dengan alasan MaxDeliveryCountExceeded, dan aplikasi boleh mengisi alasannya sendiri.
DLQ bukan tempat sampah. Pesan di sana diperiksa, penyebabnya diperbaiki, lalu pesan dikirim kembali ke antrean asal; SQS menyebut langkah ini redrive. Karena itu setiap pesan di DLQ membawa alasan dan jumlah percobaannya, dan jumlah isi DLQ dipantau.
{"waktu":"2031-03-04T08:15:02Z","level":"info","idEvent":"evt-77","langkah":"cekResi","pesan":"percobaan 1/3: TIMEOUT"}
{"waktu":"2031-03-04T08:15:07Z","level":"info","idEvent":"evt-77","langkah":"cekResi","pesan":"percobaan 2/3: TIMEOUT"}
{"waktu":"2031-03-04T08:15:16Z","level":"error","idEvent":"evt-77","langkah":"cekResi","pesan":"percobaan 3/3: TIMEOUT, dipindah ke DLQ"}Log menjawab pertanyaan apa yang terjadi pada event tertentu. OWASP Logging Cheat Sheet meminta setiap entri mencatat kapan, di mana, siapa, dan apa, ditambah pengenal interaksi yang mengikat semua entri milik satu proses; di alur kerja, pengenal itu id event. Pola Retry Azure mencatat percobaan awal yang gagal sebagai informasi dan hanya kegagalan terakhir sebagai error, supaya petugas tidak dibanjiri peringatan untuk gangguan yang pulih sendiri. OWASP juga menyebut kata sandi, kunci rahasia, dan data kartu tidak dicatat langsung di log.
