RabbitMQ: monitorar filas, DLQ e purge
O menu RabbitMQ monitora as filas de cada cliente num dashboard, acha a DLQ de cada fila e faz o purge com confirmação. Ele aparece no cliente que tem a URL da API de gerenciamento, o usuário e a senha cadastrados, e tudo passa pela Management HTTP API do RabbitMQ.
O que faz
| Plano | O que mostra e faz |
|---|---|
| Free | O painel de filas e todas as filas de todas as vhosts que o usuário enxerga: mensagens prontas, sem ack, total, consumidores e a DLQ de cada fila. Só leitura. |
| Pro e Team | Espiar as primeiras mensagens da fila ou da DLQ, com propriedades, headers e corpo. Purgar a fila inteira ou só a DLQ. |
Painel de filas do RabbitMQ: o dashboard
A aba Painel é a que abre primeiro no menu RabbitMQ: todas as filas do cliente numa tela, atualizada a cada 15 segundos (dá para trocar para 30 s ou 60 s, ou pausar). Só contagens e nomes: o conteúdo das mensagens nunca entra no painel.
| Plano | O que mostra |
|---|---|
| Free | Os totais (filas, mensagens prontas, DLQ e filas com DLQ) e a tabela de contagens (prontas, sem ack, consumidores e a DLQ pareada), com busca, ordenação (DLQ e depois prontas, da maior para a menor), o filtro "Só com DLQ" e "Agrupar variantes", que junta filas irmãs pelo nome (-retry, -dlq, -error, -memory-error, -resume, -reprocessing). |
| Pro e Team | Entrada e saída por minuto, pelos contadores do RabbitMQ (entrada: publicadas; saída: confirmadas com ack e entregues sem ack), a tendência do backlog nos últimos 5 minutos, o gráfico do cliente e o de cada fila, e os alertas abaixo. |
Clicar numa fila abre o detalhe numa gaveta, como o do pod. Espiar a fila ou a DLQ abre as mensagens no painel inferior, como os logs, e purgar pede o nome digitado, com as regras desta página.
Painel de filas: alertas e limites
- 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, com uma leitura por vez; purgar limpa o cache. O painel lê no máximo 1.000 filas e avisa quando a lista foi cortada.
- Depois de 3 erros seguidos, o painel passa a tentar a cada 60 segundos e mostra um aviso.
| 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) |
Como a DLQ do RabbitMQ é achada
- Primeiro, a fila indicada em x-dead-letter-routing-key, quando x-dead-letter-exchange é a exchange padrão ("") e essa fila existe na mesma vhost.
- Senão, uma fila irmã com o mesmo nome e o sufixo .dlq, -dlq ou _error (nessa ordem).
- Outros nomes (como .dead-letter) não são pareados: a fila aparece sozinha na lista.
- A DLQ é uma fila como as outras: espiar e purgar a DLQ usam o nome dela.
Espiar não consome, mas mexe
O RabbitMQ não tem leitura sem consumir. O Kubepier usa o get da API com ack_requeue_true: as mensagens voltam para a fila, mas marcadas como reentregues (redelivered) e podendo mudar de posição. A tela avisa antes.
Limites e tempos
| Limite | Valor |
|---|---|
| Mensagens por espiada | 20 por padrão, de 1 a 100 |
| Corpo de cada mensagem | até 64 KB |
| Purgas por cliente e serviço | 5 a cada 10 minutos |
| Tempo de cada chamada à API | 15 segundos |
Confirmações
Purgar pede que você digite o nome exato da fila (ou da DLQ). Sem o nome certo, nada é apagado.
Auditoria
- Web: cada purga vai para a auditoria da organização, no banco: quem, quando, cliente, vhost, fila, quantas mensagens havia antes e o erro, se houve.
- Desktop: cada purga vai para o arquivo kubepier-audit.log, na pasta de dados do app: quando, quem, cliente, vhost e fila, resultado e quantas foram removidas.
- Web: cada limite de backlog definido ou removido no painel (definir_limiar, remover_limiar).
- Espiar não é auditado. O corpo das mensagens nunca vai para a auditoria nem para log.
Permissões necessárias do seu lado
| Função | Usuário do RabbitMQ |
|---|---|
| Listar filas | Tag management (vê as vhosts em que tem permissão) ou monitoring (vê todas) |
| Espiar | Permissão read na fila, na vhost |
| Purgar | Permissão read na fila, na vhost (o RabbitMQ exige read para purgar) |
Crie um usuário só para o Kubepier, com a tag management e read restrito às filas que importam (configure e write vazios: ^$).
O que não é aceito
- Espiar ou purgar no Free.
- Purgar sem digitar o nome da fila, ou como membro (na web; no desktop, a partir da 2.7.0).
- Mais de 5 purgas em 10 minutos no mesmo cliente e serviço.
- Filas de vhosts que o usuário não enxerga.
Rede e rota de conexão
No cadastro do RabbitMQ, escolha a Rota de conexão. Direta: libere os IPs de saída no firewall, para a porta da API de gerenciamento. Pelo cluster: para RabbitMQ em rede privada, por um relay num cluster do cliente. Na rota Direta, um host que resolve só para IP privado responde host_privado na hora, sem tentar conectar. Conexão encerrada pelo servidor (conexao_encerrada) em geral é firewall sem os IPs de saída, TLS ou porta errados, ou limite de conexões: libere os IPs ou troque para Pelo cluster.
Erros comuns
- "sem permissão no serviço" / 401 ou 403: o usuário não tem a tag ou o read da tabela acima.
- "muitas purgas" (429 na web): espere: são 5 purgas por cliente e serviço a cada 10 minutos.
- 404: a fila ou a vhost não existe mais.
- Erro de conexão: confira a URL da API de gerenciamento (porta 15672, ou 443 em serviço gerenciado) e, na web, os IPs de saída.