Checklist de MQTT en producción: 30 comprobaciones antes del lanzamiento

Este checklist de MQTT en producción reúne las comprobaciones que separan una demo que funciona en tu mesa de una flota que funciona durante años. Repásalo antes del lanzamiento para cubrir TLS, credenciales, client IDs, comportamiento de reconexión, diseño de topics, sesiones, monitorización y alertas. Cada elemento es breve y comprobable, y el código del final muestra un cliente listo para producción que puedes adaptar a un broker de ConnectMQ.

Cómo usar este checklist

Trata cada elemento como una pregunta de sí o no y adjunta pruebas: un archivo de configuración, un resultado de test, una captura de pantalla. Los elementos que omitas a propósito deben quedar anotados con un motivo. Recorre la lista una vez durante el desarrollo, otra antes del lanzamiento y otra tras cada cambio importante de firmware o de backend.

Si todavía estás en fase de prototipo, el servidor MQTT público gratuito sirve para aprender y hacer prototipos, pero ningún punto de esta lista debe comprobarse contra él. Producción significa un broker privado con tus propias credenciales.

Sección 1: broker y seguridad

1. Broker privado operativo. El tráfico de producción circula por un broker privado, no por el servidor público de pruebas.
2. Solo TLS. Los dispositivos usan el puerto 8883 (MQTT sobre TLS) y los navegadores el 8084 (Secure WebSocket en /mqtt). Los puertos 1883 y 8083 sin cifrar no se usan en el firmware de producción.
3. Validación de certificados activada. Los clientes verifican el certificado del broker frente a una CA de confianza. No quedan flags insecure de las pruebas.
4. Estrategia de bundle de CA decidida. Los dispositivos tienen una forma de recibir certificados raíz actualizados antes de que caduquen los actuales.
5. Credenciales únicas. Cada dispositivo o gateway tiene sus propias credenciales, de modo que se pueda revocar una sin afectar a las demás.
6. Sin secretos en el control de versiones. Las credenciales viven en un almacenamiento seguro o en sistemas de aprovisionamiento, no en Git ni en paquetes de aplicaciones.
7. Revocación probada. Has revocado de verdad una credencial en staging y has confirmado que el dispositivo es rechazado.

Consulta las buenas prácticas de seguridad MQTT para entender el porqué de estos puntos.

Sección 2: identidad de los clientes y sesiones

8. Client IDs únicos y estables. Cada client ID se deriva de un número de serie o de un registro de aprovisionamiento y nunca cambia entre reinicios.
9. Sin client IDs duplicados. Dos procesos nunca comparten un ID; los duplicados se expulsan mutuamente en un bucle sin fin.
10. Clean start o sesión persistente elegidos por cliente. Los suscriptores que no pueden perder mensajes usan sesiones persistentes; las herramientas de vida corta usan sesiones limpias.
11. Expiración de sesión fijada a conciencia. En MQTT 5, el intervalo de expiración de sesión se corresponde con el tiempo que un dispositivo puede pasar sin conexión.
12. Last Will configurado. Los dispositivos definen un Last Will en un topic de estado para que el backend se entere de las desconexiones inesperadas.

Sección 3: conectividad y reconexiones

13. Reconexión automática. Los clientes se reconectan por sí solos tras una pérdida de red o un reinicio del broker.
14. Backoff exponencial con jitter. Los retrasos entre reintentos crecen y se aleatorizan, para que la flota no se reconecte al unísono.
15. Volver a suscribirse al reconectar. Si no se usan sesiones persistentes, las suscripciones se restauran en el callback de conexión.
16. Keepalive ajustado. Los valores típicos van de 30 a 120 segundos; más cortos en redes estables, más largos en redes móviles para ahorrar datos.
17. Búfer sin conexión. Los dispositivos almacenan las lecturas localmente mientras están desconectados, con un tope para proteger la memoria.
18. Fallos probados. Has desenchufado el cable de red, reiniciado la conexión con el broker y apagado y encendido dispositivos, y la recuperación ha funcionado.

Sección 4: topics, payloads y QoS

19. Árbol de topics documentado. Una convención escrita cubre niveles, nomenclatura y ejemplos. Parte de los niveles sobre los que tu backend necesita enrutar, como sitio, línea y dispositivo.
20. Sin comodines en el código de publicación. Solo los suscriptores usan + y #.
21. Formato de payload versionado. Los payloads JSON o binarios incluyen un campo de versión para poder cambiar el esquema más adelante.
22. Tamaño de payload dentro de los límites. Los mensajes caben en el tamaño máximo de mensaje de tu plan, con margen.
23. QoS elegido por tipo de mensaje. QoS 0 para telemetría de alta frecuencia en la que una pérdida es aceptable, QoS 1 para eventos y comandos. Consulta los niveles de QoS de MQTT explicados.
24. Retained messages usados con intención. Retén el estado y la configuración, no cada lectura de telemetría.

Sección 5: capacidad y límites

25. El número de conexiones cabe en el plan. El pico de conexiones simultáneas, incluidos backends, herramientas y staging, se mantiene dentro de los límites del plan con margen.
26. Tasa de mensajes estimada. Conoces los mensajes por segundo esperados y has probado con un múltiplo de esa cifra.
27. Gestión de cuotas en los clientes. Los reason codes de MQTT 5 como 0x97 (Quota exceeded) se registran y provocan un backoff en lugar de bucles de reintento cerrados.

Sección 6: monitorización, alertas y operaciones

28. Monitorización activa. Se monitorizan los clientes conectados, el flujo de mensajes y una sonda de extremo a extremo. Consulta monitorización de un broker MQTT.
29. Alertas enrutadas. Las alertas llegan a una persona, con un responsable de guardia y un runbook para broker inalcanzable, desconexiones masivas y errores de cuota.
30. Entorno de staging. Existe un broker separado para probar los cambios de firmware y backend antes de que lleguen a la flota.

Tabla resumen

Una plantilla de cliente lista para producción

Este cliente en Python, con paho-mqtt 2.x, implementa muchos de los puntos anteriores: TLS con validación de certificado, un client ID estable, un Last Will, expiración de sesión de MQTT 5, nueva suscripción al conectar, backoff y registro de reason codes. Sustituye los marcadores por las credenciales del portal de ConnectMQ.

import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

HOST = "YOUR_BROKER_HOST"
CLIENT_ID = "YOUR_CLIENT_ID"          # estable y único por dispositivo
BASE = f"plant1/line1/{CLIENT_ID}"
STATUS = f"{BASE}/status"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    print("Connected, session present:", flags.session_present)
    client.publish(STATUS, "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd", qos=1)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("Disconnected:", reason_code)   # p. ej. Quota exceeded

def on_message(client, userdata, msg):
    print("Command:", msg.topic, msg.payload.decode())

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.will_set(STATUS, "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=1, max_delay=120)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 3600   # conserva la sesión 1 hora sin conexión

client.connect(HOST, 8883, keepalive=60, clean_start=False, properties=connect_props)
client.loop_start()

while True:
    reading = {"v": 1, "temp": 21.7, "ts": int(time.time())}
    if client.is_connected():
        client.publish(f"{BASE}/telemetry", json.dumps(reading), qos=0)
    time.sleep(10)

Para añadir jitter a la primera reconexión de toda la flota, espera un número aleatorio de segundos antes de la llamada inicial a connect en el arranque.

Aplicar el checklist en ConnectMQ

En ConnectMQ, un broker MQTT gestionado, varios puntos se resuelven por ti o son fáciles de verificar. Cada broker recibe credenciales generadas con client IDs vinculados a ellas, lo que garantiza los puntos 5 y 8. TLS en el 8883 y Secure WebSocket en el 8084 usan certificados de Let's Encrypt, en los que confían los bundles de CA estándar. La protección contra inundaciones y el bloqueo de IP tras inicios de sesión fallidos repetidos añaden una capa que de otro modo tendrías que construir tú.

Para el punto 25, revisa los límites del plan: el plan Serverless gratuito admite hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB; Serverless (Paid) admite hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas; Dedicated y BYOC te dan capacidad aislada. Para los puntos 28 y 29, usa el panel del portal, el explorador de topics en vivo y las reglas de alerta por umbral con el registro de alertas, y suscríbete a $SYS/broker/connection/{clientId}/state para los gateways críticos. Un broker Serverless gratuito también es un buen entorno de staging para el punto 30.

Empieza con ConnectMQ

Crea tu broker listo para producción en app.connectmq.com, empezando con el plan Serverless gratuito y sin tarjeta de crédito. Cuando estés listo para ir más allá del piloto, lee nuestra guía para pasar de prototipo MQTT a producción, compara opciones en la guía de broker MQTT en la nube o descubre de qué se encarga por ti un broker MQTT gestionado.

Preguntas frecuentes

¿Cuál es el punto que más se olvida antes de llevar MQTT a producción?

El comportamiento de reconexión ante fallos reales. Muchos equipos solo prueban el camino feliz y descubren tormentas de reconexión o client IDs duplicados tras la primera caída.

¿Deben usar QoS 2 los dispositivos en producción?

Rara vez. QoS 1 con un tratamiento idempotente en el receptor cubre la mayoría de los casos con menos sobrecarga; reserva QoS 2 para los mensajes en los que los duplicados sean realmente perjudiciales.

¿Puedo usar el servidor MQTT público gratuito en producción?

No. Los servidores públicos los puede leer cualquiera y tienen límites estrictos. Usa un broker privado con tus propias credenciales y TLS.

¿Con qué frecuencia debo volver a pasar el checklist?

Antes de cada lanzamiento y tras cambios significativos de firmware, backend o plan. Conserva las pruebas para que las auditorías y los traspasos sean sencillos.