O monitoramento de broker MQTT diz se as mensagens estão fluindo antes que os seus clientes digam que não estão. Este guia cobre as métricas que realmente importam, conexões, taxas de mensagens, mensagens descartadas, latência e contagem de retidas, como transformá-las em alertas sem ruído e como construir uma sonda simples de ponta a ponta. Você também verá como acompanhar um broker no portal do ConnectMQ.
Por Que o Monitoramento de Brokers É Diferente
A falha de um servidor web costuma ser barulhenta: as requisições falham e as taxas de erro disparam. As falhas no MQTT muitas vezes são silenciosas. Um assinante pode continuar conectado, mas parar de receber porque a sua assinatura se perdeu após uma reconexão sem sessão persistente. Dispositivos podem estar conectados sem publicar nada porque um driver de sensor travou. A fila de um cliente offline pode crescer em silêncio até atingir os limites.
Por isso, um bom monitoramento combina três visões:
- Métricas do lado do broker: o que o broker vê, como conexões, throughput e descartes.
- Métricas do lado do cliente: o que dispositivos e aplicações veem, como falhas de conexão e número de reconexões.
- Sondas de ponta a ponta: um cliente sintético que publica e recebe, medindo se o sistema funciona como um todo.
Se as peças ainda são novas para você, comece por o que um broker MQTT faz.
As Métricas Que Importam no Monitoramento de Broker MQTT
| Métrica | O que ela mostra | Alerta típico |
|---|---|---|
| Clientes conectados | Saúde da frota, indisponibilidades, tempestades de conexão | Queda ou pico súbito em relação à linha de base |
| Tentativas e falhas de conexão | Problemas de credenciais, ataques, limites | Taxa de falhas acima do normal |
| Mensagens recebidas por segundo | Atividade de publicação | Queda para perto de zero em uma frota sabidamente ativa |
| Mensagens enviadas por segundo | Entrega aos assinantes | Divergência em relação ao fan-out esperado |
| Mensagens descartadas ou rejeitadas | Filas cheias, limites de tamanho ou de cota | Qualquer taxa sustentada diferente de zero |
| Mensagens inflight e enfileiradas | Consumidores lentos ou offline | Crescimento contínuo |
| Latência de ponta a ponta | Atraso visível ao usuário | Acima da sua meta por vários minutos |
| Contagem de retained messages | Higiene de topics, crescimento do armazenamento | Crescimento inesperado |
| Contagem de assinaturas | Vazamentos no código dos clientes | Crescimento contínuo sem novos clientes |
| Uso de recursos (auto-hospedado) | CPU, memória, descritores de arquivo | Aproximação dos limites |
Conexões
A contagem de clientes conectados é o batimento cardíaco da sua frota. Acompanhe-a como série temporal e aprenda o seu formato diário. Um penhasco significa uma indisponibilidade, um problema de rede ou um certificado expirado. Um padrão dente de serra de quedas e recuperações geralmente significa que os clientes estão sendo desconectados repetidamente, muitas vezes por client IDs duplicados ou por um keepalive curto demais em redes instáveis.
Taxas de Mensagens
As taxas de recebimento e envio mostram se os dados estão se movendo. Para uma frota que reporta a cada minuto, a taxa de recebimento deve ser razoavelmente previsível. Compare enviadas com recebidas: a razão reflete o fan-out, então uma mudança repentina significa que assinantes sumiram ou apareceram.
Mensagens Descartadas e Rejeitadas
Brokers descartam ou rejeitam mensagens por motivos concretos: payload grande demais, cota excedida, fila cheia para um consumidor lento ou mensagens QoS 0 para um cliente que não consegue acompanhar. No MQTT 5, muitos desses casos ficam visíveis para o cliente como reason codes, como 0x97 (Quota exceeded). Registre os reason codes no lado do cliente; muitas vezes eles são o diagnóstico mais rápido disponível.
Latência
A latência é o que os usuários sentem. Meça-a de ponta a ponta: coloque um timestamp na mensagem no publicador e compare na chegada a um assinante. Acompanhe percentis, não apenas médias, porque uma mediana saudável pode esconder uma cauda longa. A região também importa; veja latência de broker MQTT por região.
Retained Messages e Assinaturas
As retained messages e as assinaturas devem acompanhar o design dos seus topics. Um crescimento sem limites geralmente aponta para um bug, como nomes de topics dinâmicos contendo timestamps ou clientes que assinam de novo a cada reconexão.
Não Esqueça as Métricas do Lado do Cliente
O broker só vê o que chega até ele. Dispositivos e serviços de back-end devem reportar a própria saúde: quantas tentativas de conexão falharam e por quê, com que frequência reconectaram, quantas leituras estão no buffer offline e quais reason codes foram retornados em CONNACK, PUBACK e DISCONNECT. Publique uma mensagem de saúde compacta em um topic de status a cada poucos minutos, retida para que os dashboards sempre mostrem o valor mais recente. Quando um site fica sem sinal, esses últimos relatos muitas vezes explicam o motivo antes que alguém vá até lá.
Brokers Auto-Hospedados: De Onde Vêm as Métricas
Se você opera o seu próprio broker, as métricas vêm do próprio broker. O Mosquitto, por exemplo, publica estatísticas em topics $SYS/ como $SYS/broker/clients/connected e $SYS/broker/messages/received. Brokers em cluster geralmente expõem APIs HTTP ou endpoints de métricas para coleta. Você então conecta isso ao seu sistema de monitoramento, constrói dashboards e define alertas, além de adicionar métricas do host como CPU, memória e descritores de arquivo abertos. A documentação do Mosquitto lista os topics $SYS disponíveis.
Construa uma Sonda de Latência de Ponta a Ponta
Qualquer que seja o broker, uma sonda sintética é a verificação mais valiosa. Ela se conecta como um cliente comum, publica uma mensagem com timestamp em um topic privado, recebe-a de volta e registra o tempo de ida e volta. Esta sonda em Python usa paho-mqtt 2.x e, como está escrita, roda contra o servidor MQTT público, adequado para testes e protótipos e não para dados de produção; em produção, troque para as credenciais do seu broker privado e para a porta 8883.
import json
import statistics
import time
import uuid
import paho.mqtt.client as mqtt
HOST, PORT = "broker.connectmq.com", 1883
PROBE_ID = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{PROBE_ID}/probe"
INTERVAL = 5 # segundos entre sondagens
ALERT_MS = 500 # limite de alerta para o tempo de ida e volta
latencies = []
def on_connect(client, userdata, flags, reason_code, properties):
print("Probe connected:", reason_code)
client.subscribe(TOPIC, qos=1)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Probe disconnected:", reason_code)
def on_message(client, userdata, msg):
sent = json.loads(msg.payload)["t"]
rtt_ms = (time.time() - sent) * 1000
latencies.append(rtt_ms)
flag = " ALERT" if rtt_ms > ALERT_MS else ""
print(f"rtt={rtt_ms:.0f} ms{flag}")
if len(latencies) % 12 == 0:
recent = latencies[-12:]
print(f"last 12: median={statistics.median(recent):.0f} ms max={max(recent):.0f} ms")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"probe-{PROBE_ID}")
# Produção: client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
try:
while True:
if client.is_connected():
client.publish(TOPIC, json.dumps({"t": time.time()}), qos=1)
else:
print("ALERT: probe not connected")
time.sleep(INTERVAL)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Rode a sonda a partir das redes que os seus dispositivos usam, como a rede celular de uma fazenda ou de uma mineradora, não apenas do seu data center, e encaminhe os alertas para a sua ferramenta de plantão ou de chat.
Transformando Métricas em Alertas Úteis
A fadiga de alertas mata o monitoramento. Algumas regras práticas:
- Alerte sobre sintomas, não sobre causas. "A sonda falhou por três minutos" é acionável; "CPU em 70%" geralmente não é.
- Use linhas de base. Compare a contagem de conexões com o mesmo horário da semana anterior, em vez de um número fixo.
- Exija persistência. Dispare apenas depois que uma condição durar vários minutos, para absorver oscilações breves.
- Separe aviso de acionamento. Um crescimento lento de mensagens enfileiradas vira um ticket; zero mensagens de uma frota ativa aciona o plantão.
- Vigie os vigias. Alerte se a própria sonda parar de reportar.
Monitoramento no ConnectMQ
Com um broker MQTT gerenciado, o provedor monitora a infraestrutura, mas você ainda precisa de visibilidade sobre o seu próprio tráfego. O ConnectMQ oferece várias ferramentas no portal:
- Dashboard com uma visão geral do seu broker.
- Explorador de topics ao vivo para ver as mensagens chegando em tempo real e identificar topics que ficaram em silêncio.
- Cliente MQTT no navegador para publicar e assinar em verificações rápidas sem instalar nada.
- Visão de dispositivos que organiza os equipamentos por níveis ISA-95, útil para frotas industriais.
- Regras de alerta por limite e log de alertas, para que valores fora da faixa gerem alertas que você pode revisar depois.
Para o status de conexão por dispositivo, o broker publica o estado da conexão em $SYS/broker/connection/{clientId}/state. Um serviço de back-end pode assinar o topic de estado de clientes importantes, como gateways, e reagir quando um deles ficar offline. Combinado com as mensagens Last Will dos seus dispositivos e com a sonda acima, isso cobre a saúde tanto no nível do broker quanto no da aplicação. Fora do portal, a extensão ConnectMQ para VS Code e o Desktop MQTT explorer são úteis para inspecionar o tráfego durante o desenvolvimento.
Comece com o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e veja as suas primeiras mensagens no explorador de topics ao vivo em poucos minutos. Depois, combine-o com a sonda acima e com o checklist MQTT para produção antes de entrar no ar. O guia de broker MQTT na nuvem cobre o restante do panorama de hospedagem.
Perguntas frequentes
Qual é a métrica mais importante de um broker MQTT?
Clientes conectados combinados com uma sonda de ponta a ponta. Juntos, eles mostram se os dispositivos estão online e se as mensagens realmente fluem.
Como meço a latência MQTT?
Publique uma mensagem contendo um timestamp e calcule a diferença quando um assinante a receber. Acompanhe percentis ao longo do tempo e rode sondas a partir das redes que os seus dispositivos usam.
Por que minhas contagens de conexão caem e se recuperam em dente de serra?
As causas comuns são client IDs duplicados derrubando uns aos outros, intervalos de keepalive curtos demais para a rede ou um watchdog no dispositivo reiniciando os clientes.
Ainda preciso de monitoramento com um broker MQTT gerenciado?
Sim. O provedor vigia a infraestrutura dele, mas só você sabe o que os seus dispositivos deveriam estar enviando, então monitore o seu próprio tráfego e adicione uma sonda sintética.
