Categoría: IoT
Plataforma IoT con MQTT gestionada: broker, flujos, series temporales y paneles
Un broker MQTT, flujos que transforman los datos, una base de datos de series temporales y paneles, piezas abiertas que gestionamos como una sola plataforma en vuestra cuenta.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source (Mosquitto, Node-RED, InfluxDB 3 Core, Grafana); EMQX 5.9 o posterior, BSL 1.1
En resumen
Una plataforma IoT a medida reúne piezas de código abierto: un broker MQTT (Mosquitto o EMQX) que recibe los mensajes de los dispositivos, Node-RED para transformarlos y moverlos, TimescaleDB o InfluxDB para guardar las series temporales y Grafana para paneles y alertas. La montamos en vuestra cuenta con TLS y permisos por dispositivo, y respondemos de las copias, la vigilancia y las actualizaciones del conjunto.
¿Qué nos encargamos de mantener?
Una pila IoT hecha con piezas abiertas suele empezar como una prueba en un servidor y acabar en producción sin que nadie la haya preparado para eso. El riesgo no está en cada pieza, sino en las uniones: un flujo de Node-RED que se para, un broker que descarta mensajes o un disco que se llena de telemetría.
Broker MQTT
Mosquitto o EMQX con TLS, autenticación por dispositivo y ACL por topic.
Node-RED
Flujos en un repositorio, editor protegido y credenciales cifradas.
Series temporales
TimescaleDB o InfluxDB con retención y compresión según el uso.
Grafana
Paneles por instalación y alertas de valores y de sensores mudos.
Ingesta
Mensajes por segundo, clientes conectados y mensajes descartados en el broker.
Actualizaciones
Versiones de cada pieza fijadas, probadas juntas y actualizadas por orden.
¿Qué arquitectura recomendamos?
Los dispositivos publican por MQTT con TLS en el broker. Node-RED se suscribe a los topics, valida y transforma los mensajes y los escribe en la base de datos de series temporales; Grafana lee de ella para los paneles y las alertas. Cada pieza en su contenedor, la configuración en el repositorio y la base de datos con copias fuera del servidor.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Cientos o pocos miles de dispositivos | Mosquitto, Node-RED, TimescaleDB y Grafana en un servidor | Sencillo, barato y fácil de recuperar |
| Muchas conexiones o sin cortes tolerables | EMQX en clúster con su licencia, o varios Mosquitto por grupos de dispositivos | Más conexiones y sin un único punto de fallo |
| Solo medidas para paneles | InfluxDB en lugar de TimescaleDB | Escritura y consultas de métricas muy directas |
El puerto MQTT sin cifrar no se abre a internet. Desde Mosquitto 2.0, sin configuración explícita solo escucha en local y no admite conexiones anónimas, y así lo dejamos: cada listener, declarado y con su autenticación.
¿Para quién es?
- Industrias con máquinas o sensores en planta: quieren ver consumos, temperaturas o paradas en paneles propios, sin pagar una plataforma por dispositivo.
- Equipos de producto que añaden telemetría: su aplicación necesita recibir datos de equipos en campo y prefieren piezas estándar que conocen.
- Quien ya tiene la pila montada a mano: funciona en un servidor, pero sin copias, sin TLS o sin nadie que la actualice.
¿Qué problemas encontramos más a menudo?
- MQTT sin TLS y con un usuario compartido: todos los dispositivos usan la misma contraseña y pueden publicar en cualquier topic.
- Flujos de Node-RED solo en el servidor: sin repositorio ni copia, un error al editar no tiene vuelta atrás.
- Telemetría sin retención: la base de datos crece hasta llenar el disco y se para la ingesta.
- Sensores mudos que nadie detecta: el panel muestra el último valor y parece que todo va bien.
- Imágenes con la etiqueta latest: un reinicio cambia de versión sin que nadie lo haya probado.
- Todo en el mismo disco: la base de datos, las copias y los registros comparten volumen.
¿Cómo hacemos las copias y las actualizaciones?
Copiamos la base de datos de series temporales fuera del servidor: TimescaleDB con archivado continuo y recuperación a un momento concreto, como en PostgreSQL gestionado, e InfluxDB con sus copias propias. Los flujos de Node-RED, la configuración del broker y las ACL, y los paneles de Grafana viven en el repositorio. Restauramos periódicamente en un entorno de prueba y comprobamos que un mensaje de prueba llega del broker al panel.
Fijamos la versión de cada pieza, leemos las notas antes de cambiarla y probamos el conjunto en un entorno aparte. Actualizamos una pieza cada vez, empezando por las que no guardan estado, y vigilamos que la ingesta no baje después del cambio.
¿Cómo es el soporte día a día?
Las métricas del broker, de Node-RED y de la base de datos van a Prometheus y Grafana, como contamos en monitorización con Grafana y Prometheus, con alertas de clientes desconectados, mensajes descartados, sensores que dejan de enviar y disco. Si los mensajes tienen que pasar después a otros sistemas en grandes volúmenes, los llevamos a Kafka. La vigilancia automática es continua; la respuesta humana, el siguiente día hábil en horario laboral, dentro del SRE como servicio. Cada mes recibís un informe con versiones, incidencias, crecimiento de la telemetría y cambios hechos.
- Dispositivos y pasarelasMQTT con TLS
- Mosquitto o EMQXBroker con ACL por topic
- Node-REDTransforma y enruta
- TimescaleDB o InfluxDBSeries temporales
- GrafanaPaneles y alertas
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores cloud con las piezas en Docker o en Kubernetes, en red privada, y copias en Object Storage de Hetzner. | Muy económico para telemetría; el broker y la base de datos los operamos nosotros. |
| AWS | Las piezas en EC2 o EKS, con TimescaleDB en un PostgreSQL propio. AWS IoT Core puede hacer de broker si os encaja. | AWS IoT Core cobra por mensaje y conexión: lo comparamos con un broker propio con vuestro volumen. |
| Google Cloud | Las piezas en Compute Engine o GKE, con copias en Cloud Storage. | |
| Azure | Las piezas en máquinas virtuales o AKS, con copias en Blob Storage. | Event Grid admite MQTT; lo valoramos si el resto de vuestra plataforma ya está en Azure. |
| DigitalOcean | Las piezas en Droplets o en DOKS, con Spaces como almacenamiento de objetos. | |
| OVH | Las piezas en instancias de Public Cloud o en Managed Kubernetes, con Object Storage compatible con S3. | |
| Servidor propio | La plataforma en un servidor de la planta o de la oficina, cerca de los dispositivos. | Si la conexión a internet cae, los datos siguen guardándose en local; las copias van fuera. |
Qué incluye
- Broker MQTT con Mosquitto, o EMQX cuando necesitáis muchas conexiones, con TLS y usuarios o certificados por dispositivo.
- Permisos por topic (ACL): cada dispositivo publica solo en lo suyo y cada aplicación lee solo lo que necesita.
- Node-RED con el editor protegido por contraseña o por vuestro inicio de sesión único, y los flujos guardados en un repositorio.
- TimescaleDB o InfluxDB para la telemetría, con retención, compresión o reducción de datos antiguos definidas.
- Grafana con paneles por instalación y alertas de valores fuera de rango o de sensores que dejan de enviar.
- Copias de la base de datos, de los flujos y de la configuración del broker, con restauración de prueba.
- Métricas del broker, de Node-RED y de la base de datos, con alertas de conexiones caídas, mensajes descartados y disco.
- Actualizaciones de cada pieza ensayadas juntas en un entorno aparte, con la plataforma descrita en código.
Preguntas frecuentes
¿Mosquitto o EMQX?
Mosquitto es ligero, muy estable y suficiente para la mayoría de instalaciones con cientos o pocos miles de dispositivos, pero su versión abierta no forma clúster. EMQX escala a muchas más conexiones y trae panel, reglas y clúster, pero desde la versión 5.9 tiene licencia BSL 1.1: un solo nodo se puede usar gratis en producción y el clúster necesita licencia comercial. Las versiones Open Source hasta la 5.8 siguen con Apache 2.0, aunque sin versiones nuevas.
¿TimescaleDB o InfluxDB para la telemetría?
TimescaleDB es una extensión de PostgreSQL: consultas en SQL, uniones con vuestras otras tablas y las mismas copias que cualquier PostgreSQL. InfluxDB es una base de datos dedicada a series temporales, muy cómoda para escribir y consultar métricas. Si ya usáis PostgreSQL o queréis cruzar la telemetría con datos de negocio, TimescaleDB; si solo guardáis medidas y las miráis en Grafana, cualquiera de las dos sirve.
¿Node-RED sirve para producción?
Sí, si se trata como código: editor protegido, flujos en un repositorio con revisión de cambios, credenciales cifradas y un entorno de pruebas antes de tocar producción. Lo que no conviene es editar flujos en caliente en el servidor de producción sin copia.
¿Por qué una pila propia y no una plataforma IoT completa?
Una pila propia es más ligera y no tiene licencias por dispositivo, y cada pieza se puede cambiar por otra. A cambio, la gestión de dispositivos, los paneles para vuestros clientes y los permisos por usuario hay que montarlos. Si necesitáis eso hecho, una plataforma como ThingsBoard puede encajar mejor; os lo decimos al ver vuestro caso.
¿Qué pasa con los mensajes si cae el broker?
Los dispositivos bien configurados reconectan solos y, con QoS 1 o 2 y sesiones persistentes, el broker entrega los mensajes pendientes a los suscriptores al volver. Lo que el dispositivo no guarde mientras no hay conexión se pierde, por eso revisamos también la configuración de los clientes, no solo la del broker.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el