FAQ on Much Ado About IT

FAQ 4: How do I see the Node-RED log?

Julian Knight — Tue, 17 Mar 2020 16:28:07 +0000

Just as there are several possible ways to run Node-RED, there are several ways to access the log.

In line with most server type applications, Node-RED outputs all sorts of operational and error information to a log. In addition to Node-RED’s own logging, each node that you use may also add to the log.

You can also output your own information to the log from your flows, those methods are shown at the end of this article.

There are three categories of ways to actually run Node-RED and each will require you to access the log in a slightly different way.

Running Node-RED as a “Service”

If you install Node-RED using the script supplied for installation on a Raspberry Pi (or any other Debian-like host), Node-RED will be run as a system service. That is to say that it will be started up when the system boots. You can also do this on other platforms including Windows.

Linux

In these cases, typically system log output goes to a standard service such as syslog. Typically, the syslog output is found in a file at /var/log/syslog and you can use the tail command from a terminal command prompt to view it.

On most modern versions of Linux though, the syslog is being overtaken by logging built into the systemd service. In these cases, it is better to use the journalctl command to show the log output. This has the advantage that you only need to know the service name (node-red on a standard Pi install) and you don’t need to worry about where the actual data is stored. You can also use the more advanced features of that command to output logs in different formats.

The following command will show you the last 50 lines of the log, jumps to the last output and “follows” any further output.

journalctl -u node-red -e -f -n 50

Windows

Windows does not use log output in the same way that Linux does as it has the “Event Logs”. Typically, log output is redirected to a file and you will need to look at the startup command for Node-RED to see where the logs are being written to.

Running Node-RED manually

On all platforms, if you run Node-RED manually from the command line, the log output is shown in the same terminal. Using the keyboard command ctrl-c will both stop Node-RED and close the log.

Using a “runner” to run Node-RED

Sometimes, especially during development, it is helpful to use a “runner” application such as PM2 or nodemon to start Node-RED. These will recover from failures and can be made to “watch” for changes to files and restart automatically.

Each of these tools may have their own ways of viewing log output. For example, when using the popular pm2 runnner, the command is pm2 logs.

Changing log output levels

By default, Node-RED will show the following types of output from both Node-RED and any installed nodes:

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

You can change the logging levels to also show:

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

Or you can remove levels or turn off logging alltogether (using the off setting).

In addition, there are 2 other settings that impact logs:

metrics - Whether or not to include metric events in the log output
audit - Whether or not to include audit events in the log output

All of these settings are found (complete with instructions) in the settings.js file typically found in the userDir folder (normally ~/.node-red/settings.js).

Outputting your own information to the log

When writing flows in Node-RED, you will normally use the debug node that, by default, outputs to the debug sidebar in the Node-RED Editor (admin UI). However, you can change the settings in the debug node to also (or instead) output to the log.

In addition, you can also output to the log from a function node using the code:

node.warn('some useful text')

Output:

Mar 17 17:12:48 pi node-red[18577]: 17 Mar 17:12:48 - [warn] [function:My useful fn node] some useful text

If you give your function node a reasonably name, you will see that in the output as shown. If the node doesn’t have a name, the id will be shown, you can use that in the Editor’s search feature to find the node.

FAQ 3: What different ways are there to install Node-RED and which is best?

Julian Knight — Tue, 10 Mar 2020 09:26:00 +0000

There are several possible ways to install Node-RED, this post provides an overview and some thoughts about when you might want to use which approach.

There are three basic approaches to installing Node-RED. Which of these is “best” for you will depend on your knowledge, willingness to learn, desire or need to gain maximum flexibility and so on. Only you can work that out. It should also be noted that you should be able to mix and max these approaches if you really want to (though I can’t say that I would personally recommend that).

Global Install

This is the standard and therefore arguably by far the easiest installation.
It is good for people who are not overly familiar with their OS’s filing system or how node.js and npm work and who don’t want to be bothered to find out (that is not a criticism by the way).
It allows for multiple instances to be run if needed but all instances must use the same version of Node-RED.
It doesn’t “pollute” your home folder with the node-red and many other required node.js modules.
It is standard and most tutorials and explanations assume that this is the way it is installed.
It makes the node-red command global so you can run it from anywhere.

Advantages

Best for beginners unless you are prepared to learn about Node.js.

Disadvantages

Less flexible and possibly a little less secure. Not the best for “production” installations. Can confuse beginners into installing other Nodes and packages into global when they shouldn’t. Hard to work out where the global files are.

Local Install

This is a more “node.js way” of installing - global installations being good for exposing global commands but may sometimes be less secure.
It is a more self-contained installation. Everything can be in 1 place under a single folder structure. This makes it easier to back-up everything together. But it doesn’t force you to work this way, you can keep your userDir folder separate if you like.
It allows you to run different instances of Node-RED using different versions. Good for testing major Node-RED upgrades and for testing custom nodes or flows against different versions.
You are in control. You know where everything is because you chose to put it there.
You control access to all files and folders and so this can be a more flexible installation. You could also have different instances of node-red on the same device with different folder/file access levels. Possible development and test instances on the same device.
A good way to create a more portable installation of Node-RED since the whole folder structure can be easily copied/archived, etc.
It is my personal belief that this is also the best approach for people who want to learn how Node.js and/or Node-RED works. But then again, maybe that’s just my warped mind!

Advantages

Best for flexibility and control. Good for control of security. Best for running different versions of Node-RED in parallel on one device. Good for ease of backup/recovery and for creating distributable copies of a Node-RED application. Best for embedding Node-RED into an existing or new Node.js app.

Disadvantages

Requires some knowledge of how Node.js and npm work.

Containerised Install

Uses either Docker or snap to containerise the installation.
Isolates Node-RED from the host OS.
Allow running multiple, independent instances of Node-RED, possible using different versions.

Advantages

Best for enterprise use where containerisation is already well supported.

Disadvantages

Adds significant hidden complexity and requires good knowledge of the container technology to isolate and fix issues. Also likely to have higher resource requirements than running separate instances in other ways. Experience from the Node-RED forum suggests that a decent knowledge of Docker/snap is recommended.

There is some additional information that I wrote in a recent blog post:

https://it.knightnet.org.uk/kb/nr-qa/faq2-multiple-instances/

FAQ 2: How can I run multiple instances of Node-RED on the same server device?

Julian Knight — Fri, 06 Mar 2020 01:21:33 +0000

There are all sorts of reasons to want to run more than a single instance of Node-RED and several ways to do it.

Use the command line settings to point to a different userDir folder.

node-red -u /data/userDirectory

That lets you use different flows and configuration settings but only allows a single version of Node-RED.

You still install Node-RED in the “standard” way, globally. While this is generally simpler for complete beginners, it can lead to complexities later on. You should understand the strengths and weaknesses of npm global installs.
Install the Node-RED npm package locally rather than globally.

This gives you not only the features from 1 but also allows you to run different versions of Node-RED in parallel. The alternate-node-red-installer shows you how to do that.

It also removes the need to install Node-RED globally which can lead to unexpected security issues.

This is also the “Node.JS way” and likely to be a more welcome approach for organisations and teams that run other Node.JS services and systems.

While slightly more complex to think about initially, especially for Node.JS beginners, it helps you understand how Node.js works, is easier to work out where everything is kept and is likely to be easier to maintain in the longer term.

I use npm’s script capability to make things really easy to start manually. Here are some examples. Note that I always make the userDir folder a sub-folder of the master project folder (where Node-RED itself is installed). Keeps things neat and makes it trivial to backup the whole thing.
```
{
 ...
 "scripts": {
 "start": "node node_modules/node-red/red.js --userDir ./data",
 "start2": "set DEBUG=express:* & nodemon node_modules/node-red/red.js --userDir ./data",
 "inspect": "node --inspect node_modules/node-red/red.js --userDir ./data",
 "log": "sudo journalctl -u node-red -f -n 0 -o cat",
 "update": "npm install --unsafe-perm --production node-red",
 },
 ...
}
```
So you can start manually using npm start and start with debugging port active using npm run inspect
Run Node-RED in a container such as the Docker container.

Allows multiple versions of Node-RED along with different configurations and supporting software and services.

However, this comes at the cost of significantly greater complexity and resource overheads. Unlikely to be worth doing except in specific circumstances & needs a reasonable level of understanding of how Docker works.

You will realise that I much prefer method 2 for all of my own installations. That’s why I wrote the alternate installer which goes some way towards making installations easier and more consistent.

For running Node-RED on system startup, please see the Starting Node-RED on boot page in the docs.

FAQ 1: Should I use a function node or a flow of core nodes?

Julian Knight — Fri, 06 Mar 2020 01:16:35 +0000

There are usually many ways to achieve something in Node-RED. A common question is whether or when to use a function node or a collection of core nodes to achieve an outcome.

Whether I use one approach or the other depends on the complexity of the input vs the complexity of the output. It really doesn’t matter except that it is often easier to read a single function node that several complex change nodes as an example.

So my general rules of thumb for whether to replace a collection of nodes with a function node are:

How difficult would this be to do in a pure flow? If it is just a couple of nodes, that’s fine, if it is 10 nodes then probably not fine.
If I am using JSONata, how long is it taking me to puzzle over the JSONata code? If it is a few minutes then fine, otherwise use a function node!
Did someone already write some JavaScript that I can purloin? If so then use it!

Of course, I know JavaScript reasonably well and if you don’t then your own rules might look a little different.