Monitoramento de RabbitMQ: métricas, alertas e ferramentas

Para times de DevOps e SRE que dependem de mensageria assíncrona, o RabbitMQ é um dos componentes mais críticos da infraestrutura de produção. Filas acumulando mensagens, consumidores desaparecendo silenciosamente ou o broker bloqueando novas publicações por falta de memória são falhas que chegam ao usuário antes de chegar ao time de operações.

O monitoramento de RabbitMQ exige atenção a sinais diferentes dos demais no stack. O broker não expõe latência HTTP nem taxa de requisições por segundo: ele expõe profundidade de fila, taxa de reconhecimento de mensagens e uso de descritores de arquivo. Monitorar com as métricas erradas significa ficar cego para os problemas mais comuns do broker.

Este guia apresenta as métricas que realmente importam, como configurar a integração com Prometheus e Grafana e como estruturar alertas eficazes. Se você já tem monitoramento das APIs da plataforma, adicionar visibilidade ao broker de mensagens é o próximo passo natural para uma cobertura completa do stack.

O que é RabbitMQ e por que ele precisa de monitoramento dedicado

O RabbitMQ implementa o protocolo AMQP e atua como intermediário entre produtores e consumidores de mensagens. Uma aplicação publica uma mensagem em uma exchange; o broker roteia essa mensagem para uma ou mais filas; consumidores leem as filas e confirmam o processamento com um ack. Quando esse ciclo quebra, mensagens acumulam e nenhum componente da aplicação sinaliza o problema diretamente.

A diferença em relação ao monitoramento convencional está na natureza do componente. Servidores têm CPU e memória. Bancos de dados têm queries lentas e conexões ativas. O RabbitMQ tem filas com profundidade crescente, consumidores que desaparecem e políticas de limite de memória que bloqueiam o broker inteiro quando atingidas.

Em arquiteturas de microsserviços, um único broker pode sustentar dezenas de filas para serviços distintos. Uma fila não monitorada pode ser o ponto cego que derruba uma jornada inteira do usuário, mesmo com todos os outros componentes funcionando normalmente. Entender os pilares da observabilidade ajuda a contextualizar o RabbitMQ dentro da estratégia mais ampla de monitoramento.

Em clusters com múltiplos nós, a saúde de cada nó precisa ser acompanhada individualmente além das filas. Um nó que sai do cluster não derruba as mensagens se a política de quorum estiver configurada, mas pode redistribuir carga de forma desequilibrada e degradar a performance do broker inteiro sem nenhum alerta óbvio.

Métricas essenciais do RabbitMQ para monitorar em produção

Sete métricas formam a base de qualquer estratégia sólida de monitoramento de RabbitMQ. Conhecê-las significa saber exatamente o que observar antes que uma fila acumule mensagens suficientes para impactar o serviço.

Queue depth e mensagens não reconhecidas são os dois indicadores mais imediatos de problema. Uma fila que cresce durante um pico e se recupera depois é comportamento normal. Uma fila que cresce e nunca retorna ao baseline indica que os consumidores não estão acompanhando o ritmo de publicação ou simplesmente pararam de processar.

O uso de memória merece atenção especial. O RabbitMQ tem o parâmetro vm_memory_high_watermark que define o limite antes de o broker bloquear conexões de publicação. O padrão é 40% da memória total do host. Quando atingido, o broker entra em flow control e produtores deixam de conseguir publicar.

Acompanhe as métricas de infraestrutura do servidor host junto aos dados do broker. Picos de CPU ou I/O no host podem explicar lentidão nas filas que, analisada de forma isolada, pareceria um problema de consumidores quando a origem é a camada de sistema operacional.

Interface de gerenciamento nativa e o plugin Prometheus

O ponto de entrada mais rápido para o monitoramento de RabbitMQ é o Management Plugin, ativo por padrão nas distribuições mais recentes. Ele expõe uma interface web em http://servidor:15672/ com visão em tempo real de filas, exchanges, conexões, consumidores e nós do cluster, sem necessidade de configuração adicional.

O plugin também expõe uma API REST em /api/ que pode ser consultada por ferramentas externas. Ela retorna JSON com todos os dados visíveis na interface gráfica: contagem de mensagens por fila, taxas de publicação e entrega e estatísticas por nó. A documentação oficial de monitoramento detalha cada endpoint disponível e os campos retornados em cada resposta.

Para integrar com Prometheus, habilite o plugin dedicado com o comando rabbitmq-plugins enable rabbitmq_prometheus. Após habilitado, o RabbitMQ expõe todas as métricas em formato Prometheus na porta 15692, no endpoint /metrics. Esse endpoint retorna centenas de métricas por fila e por nó, incluindo todas as que aparecem na interface gráfica.

Como integrar RabbitMQ ao Prometheus e Grafana

Com o plugin Prometheus ativado, configure o Prometheus para coletar as métricas do RabbitMQ adicionando um job de scrape. Consulte o guia oficial do plugin para opções avançadas de configuração, como filtragem de métricas por namespace ou por fila. O intervalo recomendado é entre 30 e 60 segundos para não sobrecarregar o broker.

scrape_configs:
  - job_name: rabbitmq
    static_configs:
      - targets: ['localhost:15692']
    metrics_path: /metrics
    scrape_interval: 30s

 
Após a coleta estar ativa, conecte o Grafana ao Prometheus para visualizar os dados. A comunidade mantém um dashboard de referência no Grafana Labs com painéis pré-configurados para profundidade de fila, taxa de mensagens e uso de recursos por nó. Adapte os thresholds de alerta de acordo com o volume normal da sua operação.

Para times que já adotam OpenTelemetry como padrão de instrumentação, o Collector oferece um receptor nativo para RabbitMQ. Ele coleta as mesmas métricas do endpoint Prometheus e as encaminha para qualquer backend compatível com OTLP, permitindo correlacionar dados do broker com traces e logs das aplicações em uma única plataforma de observabilidade.

Boas práticas de alertas e thresholds recomendados

Alertas eficazes para RabbitMQ são poucos e precisos. O erro mais comum é criar um alerta para cada métrica disponível, gerando ruído que o time aprende a ignorar. A tabela abaixo resume os thresholds recomendados por nível de severidade para operações em produção.

O alerta de contagem de consumidores igual a zero em filas que sempre devem ter consumidores ativos não deve ter delay. Quando a fila fica sem consumidor, o alerta precisa disparar imediatamente, pois mensagens estão acumulando sem nenhum processamento. As boas práticas de alertas de TI recomendam mapear o contexto de negócio de cada fila antes de definir thresholds: uma fila de pedidos e uma fila de logs têm impactos muito diferentes quando ficam sem consumidor.

Configure os alertas de queue depth para disparar somente quando a condição persistir por mais de cinco minutos, não para cada pico passageiro. Uma fila que cresce momentaneamente durante uma carga alta e volta ao baseline em menos de dois minutos não é um incidente — é comportamento esperado. O alerta deve detectar a situação em que o backlog não se recupera.

Monitoramento de RabbitMQ em Kubernetes e microsserviços

Em ambientes Kubernetes, o RabbitMQ costuma ser implantado via Cluster Operator oficial. Ele simplifica a gestão do cluster e expõe métricas no formato Prometheus por padrão, compatíveis com o ServiceMonitor do kube-prometheus-stack. O monitoramento de Kubernetes deve incluir o RabbitMQ como workload de primeira classe, com dashboards e alertas integrados ao mesmo stack de observabilidade dos demais serviços.

O desafio no Kubernetes é o ciclo de vida dos pods consumidores. Quando um pod reinicia, mensagens não reconhecidas permanecem na fila até o pod voltar a consumir ou o timeout de redelivery expirar. Monitorar messages_unacknowledged por fila é especialmente importante nesses ambientes, onde reinicializações são frequentes e esperadas pelo sistema de orquestração.

Um padrão essencial para a resiliência das filas é a dead letter queue (DLQ). Mensagens que falham no processamento depois de um número configurado de tentativas são enviadas para a DLQ. Sem monitoramento da DLQ, mensagens problemáticas acumulam silenciosamente e o time de negócio só percebe o problema quando um relatório aparece incompleto ou uma jornada do usuário falha de forma intermitente e sem log de erro visível.

A plataforma OpMon oferece integração nativa com RabbitMQ, permitindo monitorar filas, nós e alertas dentro da mesma console de monitoramento da infraestrutura, sem necessidade de configurar Prometheus e Grafana separadamente para o broker.

Conclusão

O monitoramento de RabbitMQ não exige complexidade para ser eficaz. Profundidade de fila, mensagens não reconhecidas, contagem de consumidores e uso de memória são os quatro indicadores que o time deve acompanhar antes de qualquer outra métrica. Com esses dados visíveis, a maioria dos problemas é detectável antes de impactar o usuário.

A integração com Prometheus e Grafana é o caminho padrão para times que já têm essa stack ativa. O plugin nativo do RabbitMQ elimina qualquer overhead de instrumentação: basta habilitar o plugin e adicionar o scrape ao Prometheus. A interface de gerenciamento nativa cobre o monitoramento imediato sem nenhuma configuração extra.

Para times que gerenciam dezenas de filas e múltiplos clusters, a visibilidade precisa ir além de dashboards manuais. Alertas bem configurados, DLQs monitoradas e integração com o contexto de observabilidade da aplicação fazem a diferença entre detectar um problema antes de o usuário perceber e receber a ligação do cliente primeiro.

Se a sua operação de TI ainda não tem visibilidade estruturada sobre o broker de mensagens, fale com um especialista da OpServices e descubra como integrar o monitoramento de RabbitMQ à sua estratégia de observabilidade.