Hvad betyder Dead-letter queue?
En dead-letter queue, ofte forkortet DLQ, er en særskilt kø til fejlramte beskeder. En besked kan flyttes dertil, når den har fejlet et bestemt antal gange, er udløbet eller ikke kan forstås af modtageren. Formålet er at holde den normale behandling i gang uden at tabe fejlen af syne.
En DLQ løser ikke årsagen til fejlen. Den gør problemet håndterbart, hvis teamet har overvågning, ansvar og en sikker procedure for at behandle de berørte beskeder. Uden dette bliver køen blot et skjult lager af ufærdige opgaver.
Gem nok til at kunne undersøge sagen
En fejlpost bør kunne forbindes med den oprindelige opgave, beskedens identifikation, fejltype og tidspunkt. Det skal være muligt at skelne mellem en midlertidig teknisk fejl og ugyldige data. Samtidig bør payload og logs ikke gemme flere følsomme oplysninger end nødvendigt.
Fastlæg grænsen for, hvornår beskeden flyttes. For få forsøg kan gøre normale kortvarige forstyrrelser til manuelt arbejde. For mange kan blokere kapacitet og udsætte en nødvendig afklaring. Reglen bør følge fejltypen og tjenestens kontrakt frem for at være samme tal for alle beskeder.
Ret årsagen før genlevering
Inden en besked sendes tilbage, skal teamet undersøge, om noget allerede blev udført. En delvis behandling kan have oprettet en post i ét system. Genkørslen skal derfor være idempotent eller på anden måde kende tidligere virkninger. Kontroller også, om beskeden stadig er relevant: gamle data kan være blevet erstattet af en nyere hændelse. Registrér beslutningen om genkørsel, korrektion eller afslutning, så der er en forklaring på, hvad der skete med den oprindelige opgave.
Et eksempel fra praksis
Et dokumentflow afleverer godkendte felter til et økonomisystem. Et nyt feltkrav får bestemte dokumenter til at fejle. De flyttes til DLQ med dokument-ID og valideringsfejl, mens andre typer fortsætter. Efter rettelsen genkøres et lille udsnit først. Teamet kontrollerer, at posterne er korrekte og ikke dublerede, før resten behandles. En alarm på køens størrelse og alder hjælper med at opdage, at fejlene ikke blot ligger urørte.
Typiske faldgruber
- At oprette en fejlkø uden ansvarlig person eller alarm.
- At genkøre alt uden at kontrollere tidligere delvise handlinger.
- At behandle gamle hændelser, som ikke længere svarer til den aktuelle sag.
Det skal I afklare
- Gem opgave-ID, fejlårsag og nødvendig kontekst.
- Aftal overvågning, opbevaring og ejer for køen.
- Test sikker genkørsel efter en delvist udført handling.
Spørgsmål og svar
Er DLQ det samme som en log?
Nej. En log beskriver hændelser. En DLQ indeholder beskeder, som venter på en beslutning eller ny behandling. De kan forbindes, men har forskellige driftsroller.
Skal alle fejl sendes til DLQ?
Nej. Nogle fejl skal afvises direkte eller håndteres med afklaring. DLQ er relevant, når en modtaget besked ikke kan afsluttes normalt og skal bevares til kontrolleret behandling.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- AWS: SQS dead-letter queues ↗Flytning af gentagne fejl til særskilt behandling.
- Microsoft: Service Bus dead-letter queues ↗Fejlårsager, undersøgelse og genlevering af beskeder.