node-red-contrib-log4nr v1.0.3

node-red-contrib-log4nr

Introduction

This Node-RED extension log4nr is intended for managing logs at node level in a similar way than log4j does in Java. You can enable/disable certain log information according to the node type or ID, or just setting a default configuration for every node. The logging can be done when entering/exiting to/from the node so you can see how some data changed inside the node, or the data that arrives to the node, etc.

As summary, this package updates the metric method and, in addition to the existing functionality, it adds a custom functionatlity that checks which is the event and for the receive (input) and send (output) events it shows the configured information.

In order to manage to update the metric method it checks the logging messages generated, searching for the trace generated by node-red informing that a new flow deployment was done (any time that the flows are updated, or the node-red starts), and when that's happen, it'll update all the nodes existing in that moment

Package exporting data

This package exports:

• logHandler ({Object}): this is the logger that will look for the event related to the flows deployment. See the section How to use it
• setLoggingConfiguration ({Function}): overwrite the existing configuration. See the section Configuring the log levels
• updateLoggingConfiguration ({Function}): extend the existing configuration. See the section Configuring the log levels

How to use it

Basically you need to add a new logging in your settings.js file

Probably, unless you modified it, you'll have close to the bottom of the file something like this:

    // Configure the logging output
    logging: {
        // Only console logging is currently supported
        console: {
            // Level of logging to be recorded. Options are:
            // fatal - only those errors which make the application unusable should be recorded
            // error - record errors which are deemed fatal for a particular request + fatal errors
            // warn - record problems which are non fatal + errors + fatal errors
            // info - record information about the general running of the application + warn + error + fatal errors
            // debug - record information which is more verbose than info + info + warn + error + fatal errors
            // trace - record very detailed logging + debug + info + warn + error + fatal errors
            // off - turn off all logging (doesn't affect metrics or audit)
            level: "info",
            // Whether or not to include metric events in the log output
            metrics: false,
            // Whether or not to include audit events in the log output
            audit: false
        }
    },

Here you can add more loggers, so you have to create another one, it doesn't matter the name, that has to be log handler exposed by this package:

    // Configure the logging output
    logging: {
        // Only console logging is currently supported
        console: {
            ...
        },
        // this is the line to add
        log4nr: require("node-red-contrib-log4nr").logHandler
    },

This logger will be the one that checks the traces generated looking for the one that informs a flows deployment has been done.

By the way, the logHandler corresponds to an object with the parameters required by node-red as a logger.

Configuring the log levels

In the file levelsConfiguration.js there is an initial configuration that is quite generic so probably you have to extend/overwrite it. For doing this, you can use the exposed services setLoggingConfiguration or updateLoggingConfiguration. You can call these services in any place that you're application allows you, and one of this places (probably the easiest one althought not the nicest) can be the settings.js (outside the module.exports section).

These methods require as input the json object with the proper configuration. A valid configuration is defined as a JSON object as followed:

{
  "logging": {
    "levels": {
      "default": CONFIG_DEFINITION,
      "type": {
        "type_id_1": CONFIG_DEFINITION,
        "type_id_2": CONFIG_DEFINITION,
        ...
      },
      "id": {
        "id_1": CONFIG_DEFINITION,
        "id_2": CONFIG_DEFINITION,
        ...
      }
    }
  }
}

There are 3 sections (calling in somehow) with different priorities:

• default: this is the lowest priority. The configuration defined here applies to every node that doesn't have another configuration that applies to it
• type: medium priority. It checks the node type (with regular expressions). You can configure as many types as you want, each one with a configuration definition
• id: highest priority. It checks the node ID (also with regular expressions). Probably this is going to be the less used, but you can set also rules at this level

In the previous schema the CONFIG_DEFINITION is an object:

{
  "in": {
    "target": TARGETS,
    "data": DATA
  },
  "out": {
    "target": TARGETS,
    "data": DATA
  }
}

As seen, this config definition has 2 sections:

• in: this applies when entering the node, so here can be shown the information that arrives to the node
• out: this applies when exiting the node, so here can be shown the information after the node finishes the execution

As TARGETS (string compunded by texts separated by comma) there are defined currently these ones:

• nodedebug: uses the node.debug method for writting the information
• nodemetric: uses the node.metric method for writting the information
• debugtab: sends the information to the editor's debug tab

Explanations of the code