Saltar a contenido

Monitoreo

Responde: ¿qué se está midiendo, quién lo mira, y qué pasa cuando algo se rompe de noche?

La respuesta corta a la última: no pasa nada. No hay alertas. El sistema se entera de sus fallas cuando alguien mira.

Tres sistemas que no se hablan

Es el hallazgo central de esta página, y conviene verlo antes que el detalle:

flowchart TB
  subgraph A["① Cloud API"]
    CM["Métricas Prometheus<br/><i>23 métricas</i>"]
  end
  subgraph B["② Edge Pi Service"]
    EM["Métricas Prometheus<br/><i>11 métricas</i>"]
  end
  subgraph C["③ Frontend + BFF"]
    FT["Trazas OpenTelemetry"]
    SZ["SigNoz + ClickHouse<br/><i>5 tableros</i>"]
    FT --> SZ
  end

  CM -.->|"nadie<br/>recolecta"| X["∅"]
  EM -.->|"nadie<br/>recolecta"| X

  classDef ok fill:#1168bd,stroke:#0b4884,color:#fff
  classDef orphan fill:#c0392b,stroke:#7b241c,color:#fff
  class FT,SZ ok
  class CM,EM orphan
  class X orphan
Qué tiene Estado
Cloud 23 métricas Prometheus expuestas Nadie las recolecta
Edge 11 métricas Prometheus expuestas Nadie las recolecta
Frontend Stack completo de observabilidad propio, con recolector, almacenamiento y 5 tableros Bien construido. No se puede verificar si está desplegado

El recolector que existe no recolecta a los otros dos

El frontend tiene un recolector de OpenTelemetry configurado, con depuración de datos personales en dos capas y cinco tableros. Es, con diferencia, la mejor pieza de observabilidad del sistema.

Pero su configuración solo declara un receptor OTLP: no tiene receptor de Prometheus. Verificado. Eso significa que no consulta ni puede consultar las métricas del Cloud ni las del Edge: solo recibe lo que el frontend le empuja.

Los dos componentes que llevan los datos de la planta a la nube —los únicos cuya falla pierde mediciones— son exactamente los que están fuera del único sistema de observabilidad que existe.

Lo que ya se mide, y nadie mira

Vale enumerarlo porque cambia el tamaño del trabajo pendiente: las métricas que harían falta para operar el sistema ya están implementadas. Falta recolectarlas, no instrumentarlas.

En el Edge, las que importan para la planta

Métrica Para qué sirve
outbox_size Si crece y no baja, la planta no está entregando
outbox_dead_size y outbox_dead_total Datos perdidos. Es la señal del fallo descrito en troubleshooting
outbox_oldest_pending_age_seconds Cuánto hace que el evento más viejo espera
forwarder_last_success_timestamp Cuándo fue el último envío aceptado
forwarder_events_rejected_total Eventos que el Cloud rechazó

forwarder_last_success_timestamp y outbox_dead_total son, las dos juntas, todo lo que hace falta para detectar el peor fallo del sistema: el identificador de máquina que no coincide descarta todo en silencio y la primera deja de avanzar mientras la segunda crece.

Hoy esa detección requiere que una persona entre a la Pi y consulte el endpoint a mano.

En el Cloud

Cubre las dos superficies: de la ingesta mide lotes, eventos aceptados y rechazados, autenticación, limitación de tasa, disponibilidad del almacén de mediciones y desfase de versión entre el Edge y el Cloud; del ABM, autenticación, violaciones de tenant, accesos cross-tenant concedidos, invitaciones, permisos, registros y duraciones.

auth_cross_tenant_grants_total es de c708469 (2026-10-07): cuenta, por rol efectivo, los accesos que un operador de plataforma hizo sobre un cliente del que no es miembro. Es lo que permitiría detectar un uso inesperado de esa excepción, y hoy no lo mira nadie, igual que el resto de las métricas del Cloud. Cada acceso deja además un registro con el usuario y el tenant destino.

ingest_version_skew_total merece mención: se incrementa cuando el Edge envía algo que este backend no conoce. Es la única señal de que los dos repositorios se desincronizaron, y hoy no la mira nadie.

En el frontend

Trazas del navegador y del BFF, con depuración de datos personales, y cinco tableros ya definidos: diagnóstico de endpoints, errores de navegador, salud general, diagnóstico de páginas y uso por tenant.

El stack del frontend es autogestionado, y el frontend no corre en una máquina propia

Se despliega con un compose propio, y las direcciones por defecto de su recolector son nombres internos de Docker. El frontend corre en una plataforma sin servidor.

Para que las trazas lleguen a algún lado, la dirección del recolector tiene que estar configurada apuntando a un destino alcanzable desde esa plataforma. Si eso está hecho o no no se puede verificar desde los repositorios, porque esa variable vive en la consola de la plataforma.

Dicho de otro modo: el stack existe y está bien hecho; que esté funcionando es una pregunta abierta.

Lo que no se mide en ningún lado

Hueco Por qué duele
El historian No expone métricas. Es el componente que lee el PLC: el primer eslabón, y el menos observable
Trazas en el Cloud El archivo correspondiente es un comentario con un pendiente, nada más. No hay traza distribuida
Salud de punta a punta Cada componente informa de sí mismo. Nada verifica que la cadena completa funcione
La calidad del dato El historian la calcula y la escribe solo en su registro. Ver flujo de datos

Los registros

Los tres componentes emiten registros estructurados en JSON, y el Cloud y el Edge propagan un identificador de petición.

Dónde Retención
Cloud API En la plataforma de ejecución
Contenedores de la Pi 3 archivos de 10 MB por servicio, rotados. Lo anterior se descarta

La rotación de la Pi descarta lo que hace falta para diagnosticar

La rotación es necesaria: sin ella, solo el historian escribiría del orden de 550 MB por día. Pero su efecto práctico es que las líneas de arranque desaparecen, y son las que dicen si el reenvío quedó cableado y si el catálogo se cargó.

El propio runbook del empaquetado lo advierte al explicar cómo diagnosticar el modo degradado: la línea que lo delata puede haber rotado.

Un incidente de hace más de unas horas, en una Pi, no se puede investigar.

Qué construir, en orden de retorno

Nada de esto requiere instrumentar: requiere recolectar.

# Qué Por qué primero
1 Alerta sobre la cola de muertos del Edge Es la única señal de pérdida de datos. Hoy se ve entrando a la Pi
2 Alerta sobre el último envío exitoso Detecta una planta que dejó de entregar, por cualquier causa
3 Recolectar las métricas del Cloud y del Edge Agregar un receptor de Prometheus al recolector que ya existe, y alcanzarlo desde la Pi
4 Confirmar que el stack del frontend está desplegado Sin esto, los cinco tableros no sirven a nadie
5 Retención de registros más allá de la rotación Para poder investigar un incidente de ayer
6 Un chequeo de punta a punta Lo único que detecta una cadena rota en un tramo que nadie mide

Los dos primeros son los que cambian el riesgo del traspaso: sin ellos, una planta puede dejar de entregar datos durante días sin que nadie se entere, y los datos de ese período se pierden.

Relacionado