Saltar a contenido

Troubleshooting

Responde: el dashboard no muestra datos. ¿Dónde se cortó la cadena?

Un valor atraviesa siete tramos entre el PLC y el widget, repartidos en cuatro repositorios. Esta página es la que ningún repositorio puede tener: el diagnóstico de punta a punta.

Para fallas acotadas a la Raspberry Pi —el stack no levanta, un contenedor se reinicia— la tabla de síntomas del runbook del empaquetado es más directa y es la fuente de verdad. Empezá por acá cuando el stack está arriba y de todos modos no hay datos.

Cómo usar esta página

No recorras la cadena de punta a punta. Dos preguntas la parten al medio y descartan la mitad de las causas en un minuto:

flowchart TD
  S["Dashboard sin datos"] --> Q1{"¿Faltan en<br/>TODOS los widgets?"}

  Q1 -->|"no, solo algunos"| A["Problema de<br/><b>variable</b>"]
  Q1 -->|"sí"| Q2{"¿El dispositivo registra<br/>actividad reciente<br/>en el Cloud?"}

  Q2 -->|"no"| B["Problema de<br/><b>ingesta</b><br/><i>planta → nube</i>"]
  Q2 -->|"sí"| C["Problema de<br/><b>consulta</b><br/><i>el dato está guardado</i>"]

  A --> A1["§1"]
  B --> B1["§2"]
  C --> C1["§3"]

  classDef q fill:#438dd5,stroke:#2e6295,color:#fff
  classDef r fill:#1168bd,stroke:#0b4884,color:#fff
  class Q1,Q2 q
  class A,B,C r

La segunda pregunta es la más informativa de todo el sistema, y conviene saber por qué: el Cloud actualiza la marca de actividad del dispositivo solo cuando persiste al menos un evento del lote. Si registra actividad reciente, hay datos guardados y el problema es de consulta. Si no, no llegó nada o se descartó todo.

§1 · Faltan solo algunos widgets

Primero: descartar que el widget no esté cableado

18 de los 32 widgets del dashboard no consumen ninguna métrica real. No están roto: no están conectados. Un widget sin datos puede ser, simplemente, un widget todavía no implementado.

Ver catálogo de variables para el recuento, y widgets del dashboard para cuáles.

Si son los widgets de alarma: es un defecto conocido

El dato de alarma llega a la nube y se guarda bien, así que no pierdas tiempo en la Pi. Lo que falta es del lado del frontend, por dos razones distintas:

  • Los tres widgets están deshabilitados a mano y se muestran con una leyenda de «pendiente».
  • Lo almacenado con el aasPath de tres segmentos no lo encuentra una consulta por la forma canónica, que es la que fija SYS-ADR-009.

Si es otra variable concreta

En orden de probabilidad:

Causa Cómo se confirma
El aasPath del widget no existe en el catálogo Correr el validador de catálogo de variables. Es el primer paso y cuesta segundos
El tag está en tags.yaml pero no en aas_mapping.yaml El historian lo lee del PLC y lo descarta sin escribirlo. Se ve en su log como una advertencia de mapeo faltante
El mapeo existe pero está deshabilitado El Edge solo indexa las entradas habilitadas: los puntos de una deshabilitada se descartan al agrupar
La lectura de ese registro Modbus falla El historian lo registra en su log y no escribe el punto. La serie queda con huecos

Un hueco en la serie no se distingue de una máquina detenida

El historian calcula un indicador de calidad por lectura y lo escribe solo en su log: no es un tag ni un campo de la base, así que nunca llega al dashboard.

Cuando una lectura falla, el punto simplemente no existe. Para el widget, eso es idéntico a una máquina que no estaba produciendo. El log del historian es la única forma de distinguirlos.

§2 · No llega nada a la nube

El dispositivo no registra actividad reciente. Las causas, en el orden en que conviene descartarlas, porque las dos primeras son las más frecuentes y las más baratas de comprobar:

2.1 El identificador de máquina no coincide

Empezá por acá. Es la causa más costosa y la que más se parece a "todo funciona".

Comparar, carácter por carácter, el identificador configurado en la Pi contra el registrado en el Cloud para ese dispositivo.

Cómo se ve, y por qué engaña

El Cloud rechaza cada evento cuyo identificador de máquina no corresponda a la clave de API, y lo hace con un código terminal: el Edge no reintenta, lo manda a su cola de eventos muertos.

Lo que se observa:

Señal Qué muestra
Estado del Edge sano, y alcanza al Cloud
Tamaño del outbox baja con normalidad — los eventos se van descartando
Dashboard sin datos, nunca
Actividad del dispositivo en el Cloud nunca se registra ← la única señal
Alarma de aviso tampoco llega: la genera el Edge con el mismo identificador de máquina, así que se rechaza igual

Los datos de ese período se pierden definitivamente. Quedan en la cola de muertos y se purgan a los 30 días.

Que el outbox baje no es señal de que esté funcionando.

2.2 La clave de API no es válida

Revocada, vencida, mal copiada, o el dispositivo está deshabilitado.

Se distingue del caso anterior por el comportamiento del outbox: un rechazo de credencial es reintentable, así que el Edge reintenta con espera creciente y el outbox crece en lugar de bajar. El estado del Edge reporta que no alcanza al Cloud.

Al llenarse el outbox el Edge aplica contrapresión y no pierde datos: los deja en la base local esperando. A unos 18 eventos por segundo, su capacidad por defecto son aproximadamente 1,5 horas de acumulación.

El Cloud devuelve el mismo error para todos los fallos de credencial —inexistente, revocada, vencida, dispositivo de baja—, a propósito, para no dar pistas a quien pruebe claves. El motivo real está en el log del Cloud, no en la respuesta.

2.3 El Edge quedó en modo degradado

Si la URL del Cloud o la clave están vacías, el Edge arranca sin cablear el reenvío: sirve sus endpoints de estado pero no envía nada. Es el modo scaffold, y es deliberado.

Se reconoce en el estado del Edge: en modo degradado no informa el tamaño del outbox ni la versión del catálogo.

2.4 El catálogo no se cargó

Sin catálogo, el Edge descarta todos los puntos al agrupar: no puede resolver el aasPath de ninguno.

La trampa más común está documentada en el runbook del empaquetado: si la ruta del archivo de mapeo no existía al levantar el stack, Docker crea un directorio en su lugar, y el Edge no encuentra el archivo.

2.5 No se está escribiendo nada en la base local

Si el historian no escribe, el Edge no tiene nada que reenviar. Las causas están en §1, más éstas:

Causa Señal
El PLC no es alcanzable El historian registra el fallo de conexión y sigue corriendo igual, indefinidamente
Apunta al PLC simulado La configuración por defecto del empaquetado es el simulado. Hay datos, pero no son de la máquina
El token de la base local cambió después del primer arranque La base ignora los cambios de esas variables tras inicializarse. Está en la tabla del runbook

Un PLC que no responde ralentiza todo el ciclo, no solo esa variable

El historian recorre sus tags en serie, y ante un error reintenta hasta tres veces esperando cinco segundos entre intentos, con una espera bloqueante.

Un solo tag que falle agrega unos 15 segundos a un ciclo que dura un segundo. Si el PLC deja de responder por completo, el ciclo pasa de ~1 s a unos 4,5 minutos, y las variables que sí se podían leer quedan rehenes de la que falla.

Si los datos aparecen pero con muchísimo retraso, ésta es la causa. Ver calidad y resiliencia.

§3 · El dato está guardado pero no se muestra

El dispositivo registra actividad reciente, así que hay datos. El problema está entre la base y el widget.

Causa Cómo se reconoce
Ventana de tiempo del dashboard anterior al primer dato Lo más frecuente y lo más tonto. Ampliar el rango
Tenant equivocado Un usuario con acceso a varios tenants mirando el que no tiene esa máquina. Las mediciones están aisladas por tenant
Combinación de consulta inválida El Cloud rechaza combinaciones como pedir el último valor junto con series por intervalo. Devuelve un error de parámetros, no una serie vacía
Rango demasiado amplio Hay topes de cantidad de intervalos y de puntos crudos. El Cloud responde un error explícito, no un recorte silencioso
Límite de consultas alcanzado Hay un tope por usuario y por minuto. El dashboard consulta en lote, así que una carga normal es una sola petición; refrescos muy seguidos pueden agotarlo
La base de mediciones no responde La ingesta devuelve error y los dashboards quedan sin datos, pero el login y la administración siguen funcionando: si podés entrar y administrar pero ningún dashboard tiene datos, mirá acá

Cómo distinguir 'sin datos' de 'error de consulta'

Son dos cosas distintas y se confunden. El Cloud no devuelve una serie vacía ante una consulta mal formada: devuelve un error con su código. Una serie vacía significa que la consulta era válida y no había nada que devolver.

Si el widget muestra un error, es §3. Si muestra "sin datos", es §1 o §2.

Las cinco trampas de "parece sano"

Resumen de lo que miente, para tenerlo junto:

Señal que parece buena Por qué no lo es
El outbox baja También baja cuando el Cloud descarta todo por identificador de máquina
El Edge reporta sano y alcanza al Cloud Dice que la conexión funciona, no que los datos se acepten
Hay datos en la base local de la Pi No implica que lleguen a la nube
La serie tiene huecos Indistinguible de una máquina detenida: la calidad del dato no viaja
No hay alarmas El motor de alarmas no existe. La ausencia de alarmas no informa nada

Lo que hoy no se puede diagnosticar

Falta la observabilidad para cerrar el diagnóstico

El Cloud y el Edge exponen métricas que nadie recolecta. Hay un recolector en el sistema —el del frontend— pero no tiene receptor de Prometheus, así que no consulta ni puede consultar a ninguno de los dos. Ver monitoreo.

En la práctica eso significa que el diagnóstico de arriba se hace entrando a la Pi por SSH y leyendo logs de contenedores que rotan.

Lo que falta, en orden de utilidad:

  • Visibilidad de la cola de eventos muertos. Es donde terminan los datos perdidos, y hoy solo se ve entrando a la Pi. Debería ser una alarma, no una consulta manual.
  • Un recolector de métricas, para no depender de una sesión interactiva.
  • Retención de logs más allá de la rotación local, que los descarta.
  • Un chequeo de punta a punta que valide la cadena completa y no cada tramo por separado.

El inventario completo y qué construir primero está en monitoreo.

Relacionado