Alertas de filas: DLQ, fila parada e backlog
O painel de filas do Kubepier avisa quando uma fila precisa de atenção: mensagens na DLQ, DLQ crescendo, um pico de falhas, uma fila parada (sem consumo) ou backlog acima do limite. São os mesmos alertas no RabbitMQ e no Azure Service Bus, na web e no desktop. Esta página mostra quando cada alerta aparece e o que fazer.
Os alertas de fila e quando aparecem
| Alerta | Quando aparece | Nível |
|---|---|---|
| DLQ | A DLQ tem mensagens: de 1 a 99 | Atenção (100 ou mais: crítico) |
| DLQ crescendo | A DLQ subiu nos últimos 5 minutos, contando desde a última queda, com pelo menos 60 s de histórico | Crítico |
| Pico na DLQ | A DLQ ganhou 200 ou mais mensagens entre duas amostras com menos de 60 s entre elas, nos últimos 5 minutos | Crítico |
| Sem consumo | O backlog só subiu nos últimos 10 minutos e a saída ficou abaixo de 0,1 mensagem por minuto | Crítico |
| Backlog alto | Mensagens prontas acima do limite da fila (padrão 1.000) | Atenção (10 vezes o limite: crítico) |
Cada fila mostra os alertas dela na própria linha, com o nível (atenção ou crítico). No topo do painel, os totais de mensagens prontas e de DLQ também mudam de nível conforme os limites.
Onde os alertas aparecem
- Na aba Painel dos menus RabbitMQ e Azure Service Bus de cada cliente, na web e no desktop. O painel atualiza a cada 15 segundos (dá para trocar para 30 s ou 60 s, ou pausar).
- Os alertas são calculados no painel aberto, com o histórico dos últimos 60 minutos que fica só na memória (no navegador, na web; no app, no desktop). Recarregar ou fechar recomeça o histórico, e os alertas que dependem de tempo (DLQ crescendo, sem consumo) voltam a precisar da janela inteira.
- O Kubepier não manda e-mail nem notificação de alerta de fila: os alertas aparecem no painel, enquanto ele está aberto.
- No Free, o painel mostra os totais e as contagens, sem taxas, gráficos nem alertas.
DLQ com mensagens (1 a 99 atenção, 100 ou mais crítico)
A DLQ tem mensagens que a aplicação não conseguiu processar. Poucas podem ser casos isolados; 100 ou mais, um problema que precisa de dono.
- Espie a DLQ (Pro e Team) e leia o motivo: no Service Bus, DeadLetterReason e DeadLetterErrorDescription (MaxDeliveryCountExceeded, TTLExpiredException ou o que a aplicação mandou); no RabbitMQ, o header x-death (rejected, expired, maxlen ou delivery_limit).
- Procure o erro no log do pod que consome a fila, na hora das mensagens.
- Corrija a causa antes de mexer na DLQ. Depois, reprocesse com a ferramenta da aplicação ou purgue a DLQ, se as mensagens podem ser descartadas. O Kubepier espia e purga; ele não move nem reenvia mensagens.
DLQ crescendo (crítico)
A DLQ subiu nos últimos 5 minutos, contando desde a última queda, com pelo menos 60 segundos de histórico. A falha está acontecendo agora.
- Veja se houve deploy recente do consumidor: se a falha começou com ele, volte a versão (kubectl rollout undo) enquanto investiga.
- Confira o pod consumidor: CrashLoopBackOff, OOMKilled ou erro no log a cada mensagem.
- Confira a dependência que o consumidor chama (banco, API, outro serviço): fora do ar, cada mensagem falha e vai para a DLQ.
- Não purgue a DLQ enquanto ela cresce: você perde as mensagens e a evidência do problema.
Pico na DLQ (crítico)
A DLQ ganhou 200 ou mais mensagens entre duas amostras com menos de 60 segundos entre elas. O alerta fica por 5 minutos depois do pico.
- Um lote inteiro falhou de uma vez: espie as mensagens mais novas da DLQ e veja se são do mesmo produtor ou do mesmo tipo.
- Mensagem malformada de um produtor, mudança de contrato entre serviços ou uma dependência que caiu por alguns segundos são as causas mais comuns.
- Se o pico parou e a DLQ não cresce mais, trate como o alerta de DLQ com mensagens.
Sem consumo: a fila parada (crítico)
O backlog só subiu nos últimos 10 minutos, sem nenhuma queda entre as amostras, e a saída ficou abaixo de 0,1 mensagem por minuto. No RabbitMQ, a saída vem dos contadores do broker; no Service Bus, que não informa a saída, o backlog que nunca cai já é o sinal.
- Veja se há consumidor: no RabbitMQ, a coluna de consumidores da fila; zero quer dizer que nenhum processo está conectado.
- Confira o Deployment do consumidor: réplicas em zero, pods em Pending, CrashLoopBackOff ou travados sem erro.
- Confira a credencial e a permissão do consumidor na fila: uma senha trocada ou uma política SAS removida param o consumo sem derrubar o pod.
- Se o consumidor está vivo mas travado, reiniciar o deploy (Pro e Team) costuma destravar; depois, procure a causa no log.
Backlog alto (atenção acima do limite, crítico em 10 vezes)
As mensagens prontas passaram do limite da fila: por padrão, 1.000 para atenção e 10.000 para crítico. Os produtores estão mais rápidos que os consumidores.
- Compare entrada e saída por minuto (RabbitMQ) ou a variação líquida (Service Bus), e a tendência dos últimos 5 minutos: um backlog alto e descendo está se recuperando.
- Escale os consumidores, à mão (Pro e Team) ou com um HPA ou o KEDA, se o consumo é limitado pelo número de réplicas.
- Se o tempo de cada mensagem aumentou, a causa está no consumidor ou na dependência dele, não na fila.
- Se aquela fila vive acima de 1.000 e isso é normal, ajuste o limite dela na gaveta da fila (Limite de mensagens ativas, ou Usar o padrão). Na web, só o admin define, e vale para a organização; no desktop, o limite fica na sua máquina.
Limites e tempos dos alertas
- O limite de backlog de cada fila muda na gaveta da fila (Limite de mensagens ativas, ou Usar o padrão). Na web, só o admin define, no Pro e no Team; o limite vale para a organização e cada mudança vai para a auditoria (definir_limiar, remover_limiar). No desktop, o limite fica só na sua máquina, por cliente e fila.
- O histórico dos gráficos fica só na memória: na web, no navegador, e no desktop, no app. São os últimos 60 minutos desde que a tela abriu; recarregar ou fechar recomeça.
- A leitura do serviço tem cache de 10 segundos por cliente e serviço; o painel lê no máximo 1.000 filas e, depois de 3 erros seguidos, passa a tentar a cada 60 segundos.