Esta guía muestra cómo Ficticia Logistics construyó un sistema de monitorización en tiempo real sobre Google Cloud Platform, desde el sensor hasta el dashboard operativo. Sin equipo técnico propio y con un coste inferior a 150€ al mes.
El problema real
Ficticia Logistics opera 40 cámaras frigoríficas distribuidas en tres naves. Cada cámara tiene un sensor que registra temperatura, humedad y estado del compresor. En papel, tienen datos de sobra. En la práctica, esos datos viajan a ningún sitio: se almacenan localmente en el controlador de cada máquina y solo son accesibles si alguien se acerca físicamente o si el sistema genera una alarma local.
El resultado es predecible. Una cámara que lleva seis horas subiendo de temperatura de forma gradual, sin superar el umbral de alarma local, no activa ningún aviso. Para cuando alguien lo nota en la ronda manual de las 18:00, la carga ya lleva horas en riesgo. La parada no fue un fallo técnico. Fue una consecuencia de no tener visibilidad cuando todavía había margen para actuar.
Analogía
Imagina que tienes un termómetro en cada habitación de tu casa pero ninguno está conectado a ningún sitio. Si la calefacción sube demasiado, lo sabrás cuando ya tengas calor. No cuando empiece a subir. Un sistema de monitorización en tiempo real es el equivalente a tener todos esos termómetros hablando entre sí y avisándote antes de que el problema sea irreversible.
Este es el patrón que repiten empresas que han crecido rápido: la operativa escala, los activos crecen, pero la arquitectura de datos se queda en el punto de partida. Los datos existen. La conexión entre esos datos y quien puede actuar sobre ellos, no. Y añadir monitorización en tiempo real sobre esa base no resuelve nada: la monitorización en tiempo real es una capa de consumo, no un sustituto de la arquitectura. Si los datos no tienen una fuente de verdad centralizada, el dashboard muestra ruido en tiempo real en lugar de información.
La pregunta que tiene que hacerse cualquier CTO en esta situación no es "¿cómo arreglo la máquina?" sino "¿cuánto tiempo entre que algo empieza a fallar y que mi equipo lo sabe?" Si la respuesta es "horas", el problema no es mecánico.
Por qué fallan las soluciones habituales
Cuando una empresa en la posición de Ficticia decide hacer algo, suele tomar uno de estos dos caminos. Los dos comparten el mismo error de fondo.
Rondas manuales más frecuentes
La respuesta instintiva. Si el problema es que no vemos lo que pasa, hacemos rondas cada dos horas en lugar de cada seis. El operario anota temperaturas en una hoja. El problema: sigue siendo un sistema reactivo. Entre ronda y ronda, el margen de actuación sigue siendo cero. Y el coste operativo sube sin reducir el riesgo de forma proporcional.
Exportar logs cada hora a un Excel o Google Sheet
Más sofisticado en apariencia. Alguien configura una exportación periódica de los controladores a una hoja de cálculo. Aparecen gráficas. El problema: si el evento crítico ocurre a las 14:32 y el log exporta a las 15:00, tienes 28 minutos de ceguera estructural integrada en el sistema. No es un bug, es el diseño.
El error de fondo
Ambas soluciones trabajan sobre el síntoma correcto —la falta de visibilidad— pero con la herramienta equivocada. Un sistema de monitorización útil no es el que te dice qué pasó. Es el que te avisa antes de que pase. Eso requiere que el dato viaje en tiempo real desde el sensor hasta quien puede actuar, sin paradas intermedias.
Visión de conjunto del sistema
El sistema tiene cinco piezas que trabajan en cadena. Cada una hace una sola cosa. Ninguna sabe lo que hacen las demás. Eso es lo que lo hace robusto.
Las cinco piezas del sistema. El dato entra por la izquierda y llega al operario por la derecha en menos de 30 segundos.
Pub/Sub es la sala de espera. Imagina que cada sensor es un empleado que grita un número cada cinco segundos. Pub/Sub es la persona en la puerta que recibe todos esos gritos, los numera en orden y se asegura de que ninguno se pierda, aunque lleguen todos a la vez.
Dataflow es el filtro inteligente. Recibe los mensajes de Pub/Sub, comprueba que el formato es correcto, enriquece el dato con información adicional —qué nave, qué turno, cuál es el umbral máximo de esa cámara— y lo envía a BigQuery ya limpio y listo para consultar.
BigQuery es el archivo definitivo y la fuente de verdad de toda la arquitectura de datos. Todo dato que llega aquí queda registrado con su timestamp exacto. No es solo el almacén del sistema de monitorización: es el mismo lugar centralizado desde el que el resto del negocio puede tomar decisiones, cruzar datos operativos con datos comerciales y construir informes sin depender de exports manuales. Si algo pasó, BigQuery lo tiene. Si BigQuery no lo tiene, no pasó.
Cloud Function es el portero del dashboard. El frontend no puede hablar directamente con BigQuery sin exponer credenciales. La Cloud Function actúa como intermediario: el dashboard le pregunta, ella consulta BigQuery con caché de 30 segundos y devuelve el resultado. Controla quién accede y cuántas veces, lo que evita costes descontrolados.
El dashboard en React vive como un archivo estático en un bucket de Google Cloud Storage. No requiere servidor propio. Se despliega como una página web, cualquier operario con el enlace puede abrirlo en el móvil, y siempre muestra los datos de los últimos 30 segundos.
Paso a paso: cómo se construye
Lo que sigue no es un tutorial de código. Es el mapa de decisiones que un CTO necesita para validar el enfoque con su equipo técnico antes de comprometer tiempo de implementación.
Definir qué manda el sensor y con qué frecuencia
Antes de tocar ningún servicio cloud, hay que decidir el esquema del evento: qué campos contiene cada mensaje del sensor, en qué formato y cada cuánto tiempo. Para Ficticia: machine_id, temperature_c, humidity_pct, compressor_status y timestamp_utc, cada 5 segundos por máquina. Esta decisión condiciona todo lo demás. Cambiarla después cuesta caro.
Configurar el topic en Pub/Sub
Un topic es simplemente un canal con nombre al que los sensores publican sus mensajes. Se crea en minutos desde la consola de GCP. Cada sensor publica en el mismo topic; Pub/Sub se encarga de que Dataflow los reciba todos, en orden y sin pérdidas, aunque lleguen 40 a la vez.
Crear el job de Dataflow
Dataflow es el servicio gestionado de Google para procesar datos en movimiento. El job lee del topic de Pub/Sub, valida el esquema de cada mensaje, añade los metadatos de la cámara y escribe el resultado en BigQuery. GCP gestiona la infraestructura: si llegan más mensajes, escala automáticamente. No hay servidor que mantener.
Diseñar la tabla en BigQuery
La tabla de lecturas está particionada por fecha y tiene clustering por machine_id. Cuando el dashboard pregunta "dame las últimas 2 horas de la cámara 12", BigQuery solo escanea los datos de hoy y, dentro de hoy, solo los de esa cámara. El coste de cada consulta baja en un orden de magnitud.
Desplegar la Cloud Function y el dashboard en GCS
La Cloud Function expone un endpoint HTTP que el dashboard llama cada 30 segundos. Cachea el resultado en memoria con TTL de 30 segundos, evitando consultas múltiples simultáneas. El dashboard, compilado como archivos estáticos, se sube al bucket de GCS. URL lista. Sin servidor, sin contenedor, sin coste de hosting.
Nota sobre seguridad
El bucket de GCS que sirve el dashboard es público en la lectura de archivos HTML/JS, pero las credenciales de BigQuery nunca salen del backend. La Cloud Function tiene un Service Account con permisos mínimos: solo lectura sobre la tabla específica de Ficticia. Si el dashboard cae o lo comprometen, BigQuery no está expuesto.
El dashboard: qué muestra y por qué
El error más frecuente al diseñar dashboards operativos es construirlos para impresionar en una presentación en lugar de para ser útiles a las 3 de la madrugada. El criterio en Ficticia es simple: cualquier dato que no lleve a una acción concreta no tiene sitio en el dashboard.
El dashboard muestra tres bloques. El estado global: cuántas cámaras están activas y cuántas tienen alerta. La vista por máquina: temperatura actual, tendencia de las últimas dos horas y comparación con el umbral de esa cámara. El histórico de alertas: no solo las activas, sino también cuándo ocurrieron las anteriores y cuánto tardó el equipo en resolverlas.
Principio de diseño operativo
Un dashboard que requiere interpretación no es un dashboard de monitorización, es un informe de análisis. La diferencia es el tiempo entre ver el dato y saber qué hacer con él. En monitorización, ese tiempo tiene que ser cero.
Resultados y costes reales
Tres meses después de la implementación, Ficticia Logistics tiene números concretos. No estimaciones, no proyecciones.
Latencia evento → dashboard
<30 s
Antes: horas o nunca
Paradas no detectadas
0
En 90 días de operación
Alertas tempranas resueltas
7
Antes de superar el umbral crítico
Coste mensual del sistema
~150€
Pub/Sub + Dataflow + BigQuery + GCS
El desglose de costes es relevante porque la mayoría de las estimaciones que circulan sobre este tipo de sistemas son excesivas. Para el volumen de Ficticia —40 sensores enviando un evento cada 5 segundos— el coste de Pub/Sub es prácticamente cero. Dataflow es el componente más caro, alrededor de 80€ al mes. BigQuery, con la tabla particionada y el caché de la Cloud Function, supone menos de 10€ al mes. El resto es residual.
Sobre el coste de Dataflow
Si el volumen de eventos es bajo y se puede tolerar una latencia de 1-2 minutos, una Cloud Function con trigger en Pub/Sub reemplaza a Dataflow y elimina ese coste. La decisión entre ambas opciones es exclusivamente una decisión de latencia requerida, no de preferencia técnica.
¿Cuándo este sistema es demasiado?
Este sistema no es la respuesta correcta para todos los casos. Antes de comprometer tiempo de implementación, hay una sola pregunta que lo decide todo: ¿cuánto tiempo puedes permitirte no saber que algo está fallando?
El error más común es implementar el sistema más complejo porque "escala mejor" o porque "es lo que usan las empresas grandes". La complejidad tiene un coste real: más tiempo de implementación, más puntos de fallo, más conocimiento técnico necesario para mantenerlo. Si tu caso de uso tolera cinco minutos de latencia, Dataflow es una sobreingeniería que no aporta nada.
La arquitectura de datos no es una señal de madurez técnica en sí misma. Es una herramienta. La señal de madurez es saber qué herramienta no necesitas.
Este sistema asume que la capa de datos subyacente ya está resuelta: que hay una fuente de verdad, que los datos tienen estructura y que BigQuery no es el primer lugar donde alguien decide centralizar información. Si ese punto de partida todavía es un problema en tu empresa, el artículo sobre arquitectura de datos para pymes describe cómo construir esa base primero. Construir monitorización en tiempo real sobre datos dispersos es como instalar un sistema de alarma en una casa sin puertas.
La pregunta que me gustaría que te llevaras: ¿cuánto tiempo transcurre ahora mismo entre que algo empieza a fallar en tu operativa y que alguien con capacidad de actuar lo sabe? Ese número, en minutos u horas, es exactamente lo que mide el coste real de no tener este sistema.
¿Te ha resultado útil?
¿Tienes un problema que
los datos podrían resolver?
Sin formularios largos. Una conversación de 30 minutos para ver si tiene sentido.
Hablamos