Archivo de la etiqueta: Debug Node-RED

Manejo de errores en Node-RED

Node-RED proporciona los nodos Catch y Status como formas de generar flujos que pueden responder a errores. Como no existe una asociación visual directa entre un nodo Catch y los nodos a los que apunta, debe considerar cómo colocarlos para mantener los flujos legibles.

Colocarlos cerca de las partes del flujo a las que corresponden puede ayudar, pero debe tener cuidado de no sobrecargar los flujos.

Otro enfoque es agrupar todos los flujos de manejo de errores debajo del flujo principal, haciendo que la ruta “buena” sea claramente distinta de las rutas de error.

Dar a sus nodos Catch un nombre claro también es muy importante para ayudar a identificar fácilmente los escenarios que deben manejar. Cualquiera que sea el enfoque que elija, intente ser coherente en los diferentes flujos.

Manejar errores con Node-RED: https://nodered.org/docs/user-guide/handling-errors

Manejo de errores:

Si bien es fácil crear flujos que hacen lo correcto cuando todo funciona, también es importante pensar en lo que podría salir mal.

Por ejemplo, si el flujo interactúa con una base de datos externa o API, ¿qué sucede si deja de responder a las solicitudes? ¿O qué pasa si los nodos MQTT pierden su conexión con un corredor?

El manejo de errores en cualquier aplicación es esencial para garantizar que este tipo de eventos se manejen correctamente. Lo que signifique manejar el error dependerá de los requisitos de la aplicación. Es posible que desee probar una acción que falló o activar una alerta por separado, o tal vez el error sea un evento completamente esperado que es solo otra parte de la lógica de la aplicación.

Node-RED proporciona dos formas para que un nodo informe un error. Puede simplemente escribir un mensaje en el registro o puede notificar al tiempo de ejecución del error y hacer que se active un flujo.

El nodo de catch, es similar a la instrucción “try/except” en python, es decir, sirve para el manejo de excepciones.

Si el error solo se escribe en el registro, verá el mensaje en la barra lateral de depuración y la salida del registro, pero no podrá crear un flujo para manejarlo.

Si notifica al tiempo de ejecución correctamente, entonces es un error detectable que puede usarse para desencadenar un flujo de manejo de errores.

Hay un tercer tipo de error que puede hacer que el tiempo de ejecución de Node-RED se apague. Estos errores uncaughtException no se pueden manejar en el flujo y son causados por errores en los nodos.

Más información: https://techexplorations.com/guides/esp32/nore-red-esp32-project/node-red-catch/ 

Logging Errors

Cuando se produzca un error, este aparecerá en la barra de debug.

Esto muestra el mensaje de error, la fecha/hora del error y el nodo que registró el error. Al igual que con otros mensajes de depuración, al colocar el cursor sobre él, se resaltará el nodo en el espacio de trabajo. Si no está en la vista actual, al hacer clic en el nombre del nodo en la esquina superior se mostrará en el espacio de trabajo.

Nodo Catch

Si un nodo notifica al tiempo de ejecución de un error, entonces el nodo Catch puede usarse para crear un flujo para manejarlo. Si un nodo Catch detecta un error, no se registrará en la barra lateral Debug.

El mensaje enviado por Catch será el mensaje proporcionado por el nodo que informa del error. Este mensaje tendrá un conjunto de propiedades de error que proporciona información sobre el error:

 {
     "topic": ...,
     "payload": ...,
     "error": {
         "message": "An error",
         "source": {
             "id": "2e25823d.fa3f7e",
             "type": "function",
             "name": "My Function",
             "count": 1
         }
     }
 } 

Count indica cuántas veces un nodo ha lanzado este mensaje. Esta propiedad es utilizada por el tiempo de ejecución para detectar mensajes atascados en un bucle, donde se devuelven al nodo de origen, que luego registra el error nuevamente, y así sucesivamente. El tiempo de ejecución permitirá que un mensaje se repita 9 veces antes de registrar otro error, que no se puede detectar que rompa el bucle. Eliminar esta propiedad deshabilitará la verificación.

Si el mensaje ya tenía una propiedad msg.error cuando el nodo informó el error, esa propiedad se moverá a msg._error.

De forma predeterminada, el nodo Catch está configurado para ser activado por todos los nodos en la misma pestaña en el editor, pero también se puede configurar para apuntar a nodos específicos en la pestaña.

Si un nodo Catch está configurado para que lo activen todos los nodos, también se puede configurar para que solo se active en errores que aún no hayan sido detectados por otro nodo Catch. Esto le permite crear flujos de manejo de errores que se dirigen a nodos específicos y también tener un controlador de errores que capturará “todo lo demás”.

Si se registra un error desde el interior de un subflow, el tiempo de ejecución primero comprobará si hay nodos Catch dentro del subflujo. Si no hay ninguno allí, el error se propagará hasta el flujo que contiene la instancia del subflujo.

Más información: https://nodered.org/docs/user-guide/handling-errors#catchable-errors 

Errores no Registrados

Estos son los errores que un nodo escribe en el registro sin notificar al tiempo de ejecución correctamente. No se pueden manejar mediante el nodo Catch.

El nodo puede proporcionar formas alternativas de manejar el error. Por ejemplo, actualizando su propiedad de estado (que se puede monitorear con el nodo Status). Puede enviar un mensaje normalmente, pero con alguna propiedad adicional establecida para indicar el error.

Errores “uncaughtException”

Estos son un tipo particular de error de node.js que puede ocurrir cuando un nodo no puede manejar correctamente un error interno. Hacen que todo el tiempo de ejecución de Node-RED se apague, ya que eso es lo único seguro que se puede hacer.

Más información: https://nodejs.org/api/process.html#process_warning_using_uncaughtexception_correctly 

La causa típica será que un nodo haya iniciado una tarea asincrónica y esa tarea haya producido un error. Un nodo bien escrito habrá registrado un controlador de errores para esa tarea, pero si no hay uno, el error no se detectará.

Si encuentra este tipo de error, debe intentar identificar qué nodo causó el error y elevar un caso contra el autor del nodo. Esto no siempre es fácil debido a la naturaleza asincrónica del error.

Nodo Status

No todas las condiciones de error aparecerán como eventos de error que pueden detectarse en un nodo Catch. Por ejemplo, los nodos MQTT que pierden su conexión no generarán un error, pero sí un cambio de estado.

Así como el nodo Catch se puede usar para manejar eventos de error, el nodo Status se puede usar para manejar cambios en el estado de un nodo.

El mensaje enviado por el nodo Estado incluye la propiedad de estado que proporciona información sobre el estado y el nodo que desencadenó el evento.

 {
     "status": {
         "fill": "red",
         "shape": "ring",
         "text": "node-red:common.status.disconnected",
         "source": {
             "id": "27bbb5b1.d3eb3a",
             "type": "mqtt out"
         }
     }
 } 

El la visualización del estado de los nodos está habilitado de forma predeterminada, pero se puede deshabilitar en el menú > configuración

Aunque es útil como indicador visual, es aún más útil tener esta información de estado disponible en el flujo y poder tomar medidas en función del estado del nodo. Para ello disponemos del nodo “Status”.

Al añadir este nodo debe indicarse que nodos vamos a monitorizar su estado. El nodo de estado envía un mensaje cada vez que cambia el estado de los nodos supervisados. Este mensaje consta de dos objetos.

  • objeto de estado: se utiliza para obtener información de estado
  • objeto de origen: identifica el origen del mensaje mediante el ID de nodo. Cada nodo tiene una identificación de nodo única.

Debido a que la información de estado solo se envía cuando el estado cambia, generalmente es necesario colocar la información en una variable global o de flujo. Para hacer esto, pase el mensaje de estado a un nodo de función que tenga el siguiente código.

 var mqtt_status=msg.status;
 global.set('mqtt_status',mqtt_status);
 return;

Al crear funciones puedo poner un estado que sea leible desde el nod status: https://nodered.org/docs/creating-nodes/status 

Más información: http://www.steves-internet-guide.com/using-the-node-red-status-node/ 

Nodo Complete

Activa un flujo cuando otro nodo completa el tratamiento de un mensaje. Si un nodo le dice al runtime cuando ha terminado de manejar un mensaje, este nodo puede usarse para desencadenar un segundo flujo.

Por ejemplo, esto se puede utilizar junto con un nodo sin puerto de salida, como el nodo de envío de correo electrónico, para continuar el flujo.

Este nodo debe estar configurado para manejar el evento para los nodos seleccionados en el flujo. A diferencia del nodo Catch, no proporciona un modo ‘manejar todo’ que se aplica automáticamente a todos los nodos del flujo.

No todos los nodos activarán este evento; dependerá de si se han implementado para admitir esta función como se introdujo en Node-RED 1.0.

Más información: https://nodered.org/blog/2019/09/20/node-done

Debug Node-RED

El nodo debug puede ver las propiedades del mensaje enviando el mensaje al nodo de depuración.

La barra lateral de depuración muestra los mensajes que se pasan a los nodos de depuración dentro del flujo, así como ciertos mensajes de registro del tiempo de ejecución.

Junto a cada mensaje, la barra lateral de depuración incluye información sobre la hora a la que se recibió el mensaje y qué nodo de depuración lo envió. Al hacer clic en la identificación del nodo de origen, se revelará ese nodo dentro del espacio de trabajo.

El botón en el nodo se puede utilizar para habilitar o deshabilitar su salida. Se recomienda deshabilitar o eliminar los nodos de depuración que no se estén utilizando.

El nodo también se puede configurar para enviar todos los mensajes al registro de tiempo de ejecución o para enviar mensajes cortos (32 caracteres) al texto de estado en el nodo de depuración.

El nodo de depuración puede establecer su estado independientemente de lo que pase a la barra lateral de depuración. Útil si desea depurar un resumen más corto del estado, mientras muestra información más completa en la barra lateral donde hay más espacio. Para ello debe activarse en la configuración del nodo mostrar su estado.

Los mensaje de debug de la barra lateral se pueden borrar y filtrar por:

  • Todos los nodos
  • Flujo/pestaña actual
  • Nodos seleccionados.

De forma predeterminada, la barra lateral debug muestra todos los mensajes que se le pasan. Esto se puede filtrar haciendo clic en el botón para abrir el panel de opciones de filtro.

La barra lateral de depuración solo puede mostrar los 100 mensajes más recientes. Si la barra lateral muestra actualmente una lista filtrada de mensajes, los mensajes ocultos aún cuentan para el límite de 100. Si un flujo tiene nodos de depuración ruidosos, en lugar de filtrarlos desde la barra lateral, puede ser mejor desactivarlos haciendo clic en su botón en el espacio de trabajo.

El botón en el pie de página de la barra lateral se puede utilizar para abrir una ventana separada del navegador que contiene la barra lateral Depurar.

Existen una serie de acciones en bloque sobre los nodos de debug. Pueden verse en Action List (Ctrl/Cmd-Shift-P or View -> Action List) y asignar atajos de teclado a ellos:

  • core:activate-selected-debug-nodes
  • core:activate-all-debug-nodes
  • core:activate-all-flow-debug-nodes
  • core:deactivate-selected-debug-nodes
  • core:deactivate-all-debug-nodes
  • core:deactivate-all-flow-debug-nodes

Nodo para ver el payload que pasa: https://flows.nodered.org/node/node-red-show-value 

Más información:

Logging en Node-RED

Para ver los logs de node red:

  • node-red-log command (se se ha instalado con el script)
  • sudo journalctl -f -u nodered -o cat

Logging en Node-RED: https://nodered.org/docs/user-guide/runtime/logging

Node-RED usa un logger que escribe su salida en la consola. También admite el uso de módulos de registro personalizados para permitir que la salida se envíe a otra parte.

El logger de la consola se puede configurar en la propiedad de logging en su archivo de configuración settings.js:

 // Configure the logging output
 logging: {
     // Console logging
     console: {
         level: "info",
         metrics: false,
         audit: false
     }
 } 

Hay 3 propiedades que se utilizan para configurar el comportamiento del logger:

  • level: Nivel de logging a registrar
  • metrics: Cuando se establece en true, el tiempo de ejecución de Node-RED genera información sobre la ejecución del flujo y el uso de la memoria.
  • audit: Cuando se establece en verdadero, se registran los eventos de acceso a la API HTTP de administrador. El evento incluye información adicional como el punto final al que se accede, la dirección IP y la marca de tiempo.

También se puede utilizar un módulo de logging personalizado. Por ejemplo, la salida de métricas puede enviarse a un sistema separado para monitorear el desempeño del sistema. Esto luego se puede mandar a un sistema de análisis de log externo como Kibana o Logstash

Más información: https://nodered.org/docs/user-guide/runtime/logging 

El log está completamente administrado por journald fuera de node-red. Si está ejecutando en un sistema Linux utilizando el archivo de servicio systemd para ejecutar node-red, la salida se envía a /var/log/syslog.

El log se puede ver con el comando: sudo journalctl -f -u nodered -o cat

Salida de log al inicializar Node-RED:

 Start Node-RED
 Once Node-RED has started, point a browser at http://127.0.0.1:1880
 On Pi Node-RED works better with the Firefox or Chrome browser
 Use   sudo systemctl enable nodered.service  to autostart Node-RED at every boot
 Use   sudo systemctl disable nodered.service to disable autostart on boot
 To find more nodes and example flows - go to http://flows.nodered.org
 21 Nov 11:04:58 - [info] 
 Welcome to Node-RED
 ===================
 21 Nov 11:04:58 - [info] Node-RED version: v1.2.5
 21 Nov 11:04:58 - [info] Node.js  version: v12.19.1
 21 Nov 11:04:58 - [info] Linux 4.18.0-193.28.1.el8_2.x86_64 x64 LE
 21 Nov 11:04:59 - [info] Loading palette nodes
 node-telegram-bot-api deprecated Automatic enabling of cancellation of promises is deprecated.
 In the future, you will have to enable it yourself.
 See https://github.com/yagop/node-telegram-bot-api/issues/319. internal/modules/cjs/loader.js:1015:30
 21 Nov 11:05:03 - [info] RedBot version: 0.19.7 (node-red-contrib-chatbot)
 21 Nov 11:05:09 - [info] Dashboard version 2.23.4 started at /ui
 21 Nov 11:05:09 - [info] Settings file  : /root/.node-red/settings.js
 21 Nov 11:05:09 - [info] Context store  : 'memoryOnly' [module=memory]
 21 Nov 11:05:09 - [info] Context store  : 'file' [module=localfilesystem]
 21 Nov 11:05:09 - [info] User directory : /user/.node-red
 21 Nov 11:05:09 - [info] Server now running at https://127.0.0.1:1880/
 21 Nov 11:05:09 - [info] Active project : Demo_Proyecto
 21 Nov 11:05:09 - [info] Flows file     : /user/.node-red/projects/Demo_Proyecto/flow.json
 21 Nov 11:05:09 - [info] Starting flows
 21 Nov 11:05:09 - [info] Started flows
 21 Nov 11:05:09 - [info] [mqtt-broker:2ac34a26.7bd096] Connected to broker: mqtt://localhost:1883 

Flow Debugger

Una de las características que se mejorará en las siguientes versiones de Node-RED es un depurador de flujo adecuado.

Node-RED proporciona el nodo de depuración para ayudar al desarrollador a comprender lo que sucede en su flujo. Son herramientas útiles, pero tienen sus límites. Solo puede depurar en los puntos en los que ha agregado un nodo al flujo. Cuando tiene un flujo que involucra múltiples ramas y eventos de tiempo, puede ser difícil ver cómo fluyen los mensajes en cada rama al mismo tiempo.

Flow Debugger permitirá al desarrollador establecer puntos de interrupción a lo largo de su flujo. Cuando un mensaje llega a un punto de interrupción, el tiempo de ejecución se pausará y los mensajes dejarán de fluir. Luego, el desarrollador puede inspeccionar el flujo en diferentes puntos para inspeccionar los mensajes que esperan ser entregados.

Cuando se ejecuta con el depurador habilitado, el usuario podrá visualizar el rendimiento de sus flujos, para ver dónde se está gastando el tiempo o si existen cuellos de botella que podrían optimizarse.