Can Node-RED monitor its own uptime?

[Peter Varadi]

Hi 

My process monitor restarts node-red immediately after a crash and I have a flow that crashes node-red. Because the flow is triggered on startup, node-red ends up in a rapid restart cycle. I discovered the restarts only by inspecting the log file. There were indirect Flow Editor clues such as the Deploy button staying gray and the debug pane not responding. But from my user perspective, this was pretty much a silent failure of node-red.

Can there be visual clues in the Node-RED UI to indicate that a process restart has occurred? It can't be a node because it might not get executed before the crash occurs. An "uptime since last deployment" field in the UI might do the trick. 

Peter

[Jan Van den Audenaerde]

Contrary to what you say can't you not create a flow that measures the uptime ?  You will need an inject node that triggers a timestamp at startup.  So this timestamp will be the timestamp of the last time nodered got deployed.  Based on this timestamp and the actual time you can calculate the uptime which you can display in an UI node.

kr Jan.

[Peter Varadi]

Hi Jan,

thanks for the suggestion and that is what I have done initially. I put the uptime into the status message of a function node. It is very handy for spotting the occasional crash (always because of some node behavior mind you, not because of core node-red).

Still, this is unsatisfactory when the crash occurs before that node is executed, which is what happened to several of us at separate times. The UI became unresponsive and our initial instinct was to look for networking and authentication problems, which we had encountered before and can look the same. We deploy node-red for late-stage customization by our customers and this seemingly little issue can be a hurdle in end-user acceptance. The last thing you want to hear your customer say is "Hey, what's going on?"

Another solution is to pipe the log itself into Node-RED, which is what another email thread suggests, but that has the same problem and seems a bit heavy-handed.

Peter

[Julian Knight]

Piping the log through to a web page can be very useful when your users have no access to the server and you don't want to tie up support resources. You will want to limit the number of lines though.

In reality, in a production system, you would have an independent monitor for key services which would alert if the service abnormally terminates. It is certainly easy enough to do this on a Linux or Windows system. Logs, service events, system events and uptime should always be monitored independently of the actual system. It would be easy enough to arrange for the startup of your Node-RED service to create a .pid file and to have a monitor that looks at the creation timestamp of that file.

[Peter Varadi]

Hi Julian,

we indeed monitor processes on all production serves but that does not necessary help the flow developer who's focus is on the Node-RED UI alone. We are also trying to enlarge the pool of node-red end-users and flow developers. Having to pay attention to a separate tool for process monitoring constitutes an obstacle to many that should not be underestimated for user acceptance. A few key metrics in the node-RED UI do not replace the monitor but certainly make node-RED more self-contained.

Peter

[Julian Knight]

Good points and absolutely reasonable. :-)

[Jan Van den Audenaerde]

Hi Peter,
NR crashes is for me a pretty rare phenomenon. It seems that for you this is not the case. Should you not try to troubleshoot first why you do have those frequent crashes?
Kr jan

[Peter Varadi]

A node-red crash is not the only reason why node-red gets restarted. There reasons include scheduled/unscheduled server reboot and process monitoring gone haywire.

You are correct, a crash happens rarely and usually during development. I have no problem with nod-red being crashed by improper exception handling in a third-party node (in my case I was trying to access a port for which node-red has no permission), there just has to be a visual indication in the UI that the node-red instance has been restarted in the background.

The Node-RED roadmap suggests that a single UI will be able to interacts with several server instances. I think it will be even more important there to have some small amount of performance info available in the UI.

 

Peter