Atualmente, a fila Pub/Sub observability_event_queue em nossa plataforma está utilizando a retenção padrão de 7 dias, e não há um consumer configurado para a Dead Letter Queue (DLQ).

Isso tem causado inúmeros alertas como este no channel #alerts do Slack, causando potencial perda de eventos quando ocorre falhas no processamento e até mesmo quando atrasado ou interrompido. A fila observability_event_queue é responsável por transmitir eventos de observabilidade de batches para a tabela observability_event do database mdmmaster no PostgreSQL, para que o job Quartz ObservabilityEventSenderJob realize o sync dos eventos da Carol para o SmartLink.

Para mitigar esse problema, precisamos implementar uma nova funcionalidade que aumente a confiabilidade e resiliência deste mecanismo de processamento de eventos em nossa plataforma.

Objetivo

Implementar uma feature para evitar a perda de eventos na fila Pub/Sub observability_event_queue do GCP, garantindo que os eventos sejam processados mesmo em situações de alta latência ou falhas temporárias.

Benefícios

• Redução de Perda de Dados: Com a implementação da DLQ, eventos que não puderem ser processados serão armazenados em uma fila de fallback para tentativa posterior.
• Aumento de Confiabilidade: Melhora a confiança no sistema, sabendo que os eventos não serão perdidos em casos de falha ou atrasos no processamento.
• Facilidade de Monitoramento: Implementação de métricas e alertas para monitorar o status da fila DLQ e do consumer, facilitando a identificação e resolução de problemas.
• Escalabilidade: Melhor gestão de picos de demanda, permitindo que o sistema possa escalar de maneira mais eficiente.

Escopo:

• Configurar a Dead Letter Queue (DLQ): :::Prioritário:::
  • Criar uma nova fila Pub/Sub dedicada para a DLQ.
  • Configurar a observability_event_queue para redirecionar mensagens para a DLQ após um número definido de tentativas falhas.
• Aumentar a Retenção de Mensagens na observability_event_queue:
  • Ajustar as configurações da fila Pub/Sub para aumentar o período de retenção de 7 dias para um período mais adequado ao nosso fluxo de trabalho, conforme necessário.
  • Reforçar políticas de retries e backoff em caso de falha de conexão com o Postgres (onde ocorre maior incidência de problemas).
• Implementar um consumer para a DLQ:
  • Implementar um novo handler que consuma as mensagens da DLQ.
  • Configurar políticas de retries e backoff exponencial para reprocessamento.
• Monitoramento e Alertas: :::Prioritário:::
  • Implementar métricas de monitoramento.
  • Configurar alertas para casos de acúmulo de mensagens na DLQ ou falhas frequentes no processamento.
  • Definir forma para consumir os dados para análise:
    • Sugestão: BQ Subscription para levar os dados para uma tabela no BQ.