La monitorización de un broker MQTT te dice si los mensajes fluyen antes de que tus clientes te digan que no lo hacen. Esta guía cubre las métricas que de verdad importan (conexiones, tasas de mensajes, mensajes descartados, latencia y recuento de retenidos), cómo convertirlas en alertas sin ruido y cómo construir una sonda sencilla de extremo a extremo. También verás cómo vigilar un broker en el portal de ConnectMQ.
Por qué la monitorización de un broker es diferente
El fallo de un servidor web suele ser ruidoso: las peticiones fallan y las tasas de error se disparan. Los fallos de MQTT a menudo son silenciosos. Un suscriptor puede seguir conectado pero dejar de recibir porque perdió su suscripción tras una reconexión sin sesión persistente. Los dispositivos pueden estar conectados sin publicar nada porque se colgó el driver de un sensor. La cola de un cliente desconectado puede crecer en silencio hasta alcanzar los límites.
Por eso una buena monitorización combina tres vistas:
- Métricas del lado del broker: lo que ve el broker, como conexiones, rendimiento y descartes.
- Métricas del lado del cliente: lo que ven los dispositivos y las aplicaciones, como fallos de conexión y número de reconexiones.
- Sondas de extremo a extremo: un cliente sintético que publica y recibe y mide si el sistema funciona en su conjunto.
Si las piezas son nuevas para ti, empieza por qué hace un broker MQTT.
Las métricas que importan en la monitorización de un broker MQTT
| Métrica | Qué te dice | Alerta típica |
|---|---|---|
| Clientes conectados | Salud de la flota, caídas, tormentas de conexión | Caída o pico repentino frente a la referencia |
| Intentos y fallos de conexión | Problemas de credenciales, ataques, límites | Tasa de fallos por encima de lo normal |
| Mensajes recibidos por segundo | Actividad de publicación | Caída a casi cero en una flota que suele estar activa |
| Mensajes enviados por segundo | Entrega a los suscriptores | Desviación respecto al fan-out esperado |
| Mensajes descartados o rechazados | Colas llenas, límites de tamaño o de cuota | Cualquier tasa sostenida distinta de cero |
| Mensajes en vuelo y en cola | Consumidores lentos o desconectados | Crecimiento constante |
| Latencia de extremo a extremo | Retraso visible para el usuario | Por encima de tu objetivo durante varios minutos |
| Recuento de retained messages | Higiene de topics, crecimiento del almacenamiento | Crecimiento inesperado |
| Recuento de suscripciones | Fugas en el código de los clientes | Crecimiento constante sin clientes nuevos |
| Uso de recursos (autoalojado) | CPU, memoria, descriptores de archivo | Cerca de los límites |
Conexiones
El número de clientes conectados es el pulso de tu flota. Síguelo como serie temporal y aprende su forma diaria. Un desplome indica una caída, un problema de red o un certificado caducado. Un patrón en diente de sierra de caídas y recuperaciones suele significar que los clientes se desconectan repetidamente, a menudo por client IDs duplicados o por un keepalive demasiado corto en redes inestables.
Tasas de mensajes
Las tasas de recepción y envío muestran si los datos se mueven. En una flota que informa cada minuto, la tasa de recepción debería ser bastante predecible. Compara los enviados con los recibidos: la proporción refleja el fan-out, así que un cambio brusco significa que han desaparecido o aparecido suscriptores.
Mensajes descartados y rechazados
Los brokers descartan o rechazan mensajes por motivos concretos: payload demasiado grande, cuota superada, cola llena por un consumidor lento o mensajes QoS 0 dirigidos a un cliente que no da abasto. En MQTT 5, muchos de estos casos son visibles para el cliente como reason codes, por ejemplo 0x97 (Quota exceeded). Registra los reason codes en el lado del cliente; a menudo son el diagnóstico más rápido disponible.
Latencia
La latencia es lo que sienten los usuarios. Mídela de extremo a extremo: pon una marca de tiempo al mensaje en el publicador y compárala a su llegada a un suscriptor. Sigue percentiles, no solo medias, porque una mediana sana puede ocultar una cola larga. La región también importa; consulta la latencia de un broker MQTT por región.
Retained messages y suscripciones
Los retained messages y las suscripciones deberían ajustarse a tu diseño de topics. Un crecimiento sin límite suele apuntar a un fallo, como nombres de topic dinámicos que contienen marcas de tiempo o clientes que vuelven a suscribirse en cada reconexión.
No olvides las métricas del lado del cliente
El broker solo ve lo que le llega. Los dispositivos y servicios de backend deberían informar de su propia salud: cuántos intentos de conexión fallaron y por qué, con qué frecuencia se reconectaron, cuántas lecturas hay en el búfer sin conexión y los reason codes devueltos en CONNACK, PUBACK y DISCONNECT. Publica un mensaje de salud compacto en un topic de estado cada pocos minutos, retenido para que los paneles muestren siempre el último valor. Cuando un sitio se queda a oscuras, esos últimos informes suelen explicar el porqué antes de que nadie vaya a verlo.
Brokers autoalojados: de dónde salen las métricas
Si ejecutas tu propio broker, las métricas proceden del propio broker. Mosquitto, por ejemplo, publica estadísticas en topics $SYS/ como $SYS/broker/clients/connected y $SYS/broker/messages/received. Los brokers en clúster suelen exponer API HTTP o endpoints de métricas para su recogida. Después las conectas a tu sistema de monitorización, construyes paneles y defines alertas, y añades métricas del host como CPU, memoria y descriptores de archivo abiertos. La documentación de Mosquitto enumera los topics $SYS disponibles.
Construye una sonda de latencia de extremo a extremo
Uses el broker que uses, una sonda sintética es la comprobación más valiosa. Se conecta como un cliente normal, publica un mensaje con marca de tiempo en un topic privado, lo recibe de vuelta y registra el tiempo de ida y vuelta. Esta sonda en Python usa paho-mqtt 2.x y funciona tal cual contra el servidor MQTT público gratuito, pensado para pruebas; para producción, cambia a las credenciales de tu broker privado y al puerto 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 sondas
ALERT_MS = 500 # umbral de alerta para el tiempo de ida y vuelta
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}")
# Producción: 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()
Ejecuta la sonda desde las redes que usan tus dispositivos, no solo desde tu centro de datos, y reenvía sus alertas a tu herramienta de guardias o de chat.
Convertir métricas en alertas útiles
La fatiga de alertas mata la monitorización. Algunas reglas prácticas:
- Alerta sobre síntomas, no sobre causas. "La sonda lleva tres minutos fallando" es accionable; "CPU al 70 %" normalmente no.
- Usa referencias. Compara el número de conexiones con la misma hora de la semana anterior en lugar de con una cifra fija.
- Exige persistencia. Dispara solo cuando una condición dure varios minutos, para absorber los cortes breves.
- Separa avisos de guardias. Un crecimiento lento de los mensajes en cola es un ticket; cero mensajes de una flota activa es una llamada de guardia.
- Vigila a los vigilantes. Alerta si la propia sonda deja de informar.
Monitorización en ConnectMQ
Con un broker MQTT gestionado, el proveedor monitoriza la infraestructura, pero tú sigues necesitando visibilidad sobre tu propio tráfico. ConnectMQ te ofrece varias herramientas en el portal:
- Panel con una visión general de tu broker.
- Explorador de topics en vivo para ver llegar los mensajes en tiempo real y detectar topics que se han quedado en silencio.
- Cliente MQTT en el navegador para publicar y suscribirte en comprobaciones rápidas sin instalar nada.
- Vista de dispositivos que organiza los equipos por niveles ISA-95, útil para flotas industriales.
- Reglas de alerta por umbral y registro de alertas, para que los valores fuera de rango generen alertas que puedas revisar después.
Para el estado de conexión de cada dispositivo, el broker publica el estado de la conexión en $SYS/broker/connection/{clientId}/state. Un servicio de backend puede suscribirse al topic de estado de los clientes importantes, como los gateways, y reaccionar cuando uno se desconecta. Combinado con los mensajes Last Will de tus dispositivos y la sonda anterior, eso cubre la salud tanto a nivel de broker como de aplicación. Fuera del portal, la extensión de ConnectMQ para VS Code y el explorador MQTT de escritorio resultan prácticos para inspeccionar el tráfico durante el desarrollo.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y observa tus primeros mensajes en el explorador de topics en vivo en cuestión de minutos. Después combínalo con la sonda anterior y con el checklist de MQTT en producción antes de salir a producción. La guía de broker MQTT en la nube cubre el resto del panorama de alojamiento.
Preguntas frecuentes
¿Cuál es la métrica más importante de un broker MQTT?
Los clientes conectados combinados con una sonda de extremo a extremo. Juntos muestran si los dispositivos están en línea y si los mensajes fluyen de verdad.
¿Cómo mido la latencia de MQTT?
Publica un mensaje que contenga una marca de tiempo y calcula la diferencia cuando lo recibe un suscriptor. Sigue los percentiles a lo largo del tiempo y ejecuta sondas desde las redes que usan tus dispositivos.
¿Por qué mi número de conexiones cae y se recupera en diente de sierra?
Las causas habituales son client IDs duplicados que se expulsan entre sí, intervalos de keepalive demasiado cortos para la red o un watchdog en el dispositivo que reinicia los clientes.
¿Sigo necesitando monitorización con un broker MQTT gestionado?
Sí. El proveedor vigila su infraestructura, pero solo tú sabes qué deberían enviar tus dispositivos, así que monitoriza tu propio tráfico y añade una sonda sintética.
