ContacteEstàndard de DLQ a EventHub
Navegació
| ⬅️ Estàndard de Schemas | ➡️ Decisió del clúster |
|---|
Quan he de consultar aquest estàndard?
Consulta aquest document quan:
- estàs omplint el camp
Requiere_DLQde la plantilla de sol·licitud, - necessites gestionar missatges que no s’han pogut processar correctament,
- dissenyeu l’estratègia de gestió d’errors d’un connector o una integració.
Canigó – Estàndard obligatori
1. Què és una DLQ?
Una Dead Letter Queue (DLQ) és un topic Kafka destinat a recollir els missatges que no han pogut ser processats correctament per un consumidor o connector, per tal que no es perdin i puguin ser analitzats i reprocessats posteriorment.
2. Quan cal usar DLQ
Marca Requiere_DLQ = SI a la plantilla quan es compleixi alguna d’aquestes condicions:
| Situació | DLQ recomanada |
|---|---|
| Connector Sink que pot fallar per errors de la BBDD destí | ✅ Sí |
| Connector Source CDC on errors de format poden bloquejar el flux | ✅ Sí |
| Integració crítica on la pèrdua de missatges no és acceptable | ✅ Sí |
| Topic de notificació no crítica amb consumidor tolera pèrdues | ❌ No necessari |
| Processament simple on l’error és recuperable des de l’origen | ❌ No necessari |
En cas de dubte, consulta amb l’Oficina EventHub durant el procés de validació.
3. Naming del topic DLQ
El nom del topic DLQ segueix el patró estàndard amb el sufix -dlq:
| Format | Exemple | |
|---|---|---|
| Topic principal | {codi}-{descripció}[-entorn] |
a1234-sync-clients-pre |
| Topic DLQ associat | {codi}-{descripció}-dlq[-entorn] |
a1234-sync-clients-dlq-pre |
El nom es declara a la plantilla de sol·licitud. L’Oficina EventHub valida el naming i crea el topic DLQ com a recurs governat independent.
4. Configuració de la DLQ
La configuració del topic DLQ la defineix l’Oficina EventHub en funció del cas d’ús. Els paràmetres habituals són:
| Paràmetre | Valor habitual | Nota |
|---|---|---|
| Particions | Iguals al topic principal | Mantenir coherència |
| Retenció | 30 dies | Superior a l’estàndard; justificada per la necessitat d’anàlisi |
| Cleanup policy | delete |
No s’usa compact en DLQs |
| Accés | Restringit al propietari del topic | No és un topic de lectura general |
5. Responsabilitats
| Rol | Responsabilitat |
|---|---|
| Propietari del topic / connector | Monitoritzar el lag del topic DLQ. Actuar quan hi ha missatges acumulats. |
| Equip de l’aplicació | Implementar el procés de reprocessament. Analitzar la causa dels missatges a la DLQ. |
| Oficina EventHub | Crear i governar el topic DLQ. Alertar si detecta acumulació anòmala durant el check diari. |
6. Monitorització
El topic DLQ s’ha de monitoritzar com qualsevol altre topic actiu:
- Supervisar el consumer lag del topic DLQ. Si creix de forma sostinguda, indica que hi ha missatges no processats acumulant-se.
- Configurar una alerta quan el lag del topic DLQ superi un llindar definit (consultar amb l’Oficina el llindar adequat per al cas d’ús).
- Revisar periòdicament els missatges del topic DLQ per detectar patrons d’error recurrents.
7. Procediment de reprocessament
Quan s’acumulen missatges a la DLQ:
- Analitzar la causa: revisar els logs del connector o de l’aplicació per identificar per què els missatges han fallat.
- Corregir el problema: resoldre l’error a l’origen (BBDD destí, format del missatge, configuració del connector, etc.).
- Reprocessar els missatges: rellegir els missatges del topic DLQ i reenviar-los al flux principal un cop resolt el problema. El procediment específic depèn del tipus d’integració — consultar amb l’Oficina EventHub.
- Verificar: confirmar que els missatges reprocessats s’han processat correctament i que el lag del topic DLQ ha tornat a zero.
⚠️ No eliminar missatges del topic DLQ sense haver identificat i resolt la causa del problema.