Request a "Live Flow Activity Monitoring" feature in Node-RED that provides a real-time visual report of all active flows and processes. This dashboard-like view would include:
Currently running flows with status indicators
Active loops and their counts in specific flows
Resource utilization per flow, offering a "task manager"-style overview
Flowing Data Preview: The ability to select a flow and view the real-time data passing through it, aiding in monitoring and troubleshooting the flow’s content.
This feature enhances visibility into flow activities and data, making it easier to manage and debug complex workflows.
I think you may have misinterpreted how Node-RED works.
The entire flow (all tabs) run on startup and continue to run. All deployed nodes are always live and ready to process incoming messages.
While we talk about flows in the context of what you see in the Editor, under the skin, there is only 1 flow really.
The resources used by Node-RED are mostly defined by the installed nodes and the deployed nodes. On top of that are the resources being managed as part of message flows.
Also worth noting that, although Node-RED talks about message flows and so makes them seem like a water pipe analogy, this is not really true. A message trigger (either a trigger node or some event node) creates a temporary chunk of data that is passed in turn to the message callback function of each connected node.
Having said all that, there are some nodes already that help with monitoring and debugging and you should start with those.
To add/expand what @TotallyInformation already said, Node.js runs single threaded, meaning it's only doing one thing at a time. It doesn't mean everything runs consecutively though. Node.js (and therefore Node-RED) can do native calls that will be handled by the OS or do calls to native code that's executed asynchronously, but this is not something you could meaningfully measure resource utlilization from Node.js appllication code itself. In contrast, Chrome can show you a task manager presentation of the tabs you have open, but this is because Chrome runs each tab in a separate process and Chrome itself is not written in JavaScript.
I definitely would be possible to visualize the data flow and the counts of the messages passing through and calculating statistis of the time taken at each step, but like already mentioned, you can already do using so 3rd party nodes like this one. The core team has stated many times in the past the the flow editor is not intended as a dashboad. I haven't been around much lately so I can't say that for sure, but checking out the available 3rd party nodes is likely you're best bet to achieve something like this.
This is a REALLY bad idea. The editor already limits the size of messages shown in the debug sidebar so as not to overwhelm the websocket connection between the backend and the editor, adding an event for EVERY single message in the flow would cause the editor to grind to a halt for any flow under even minimal load.
I do wonder though (just some random Saturday thoughts) whether it wouldn't be a good idea to have a standard for nodes to add metrics. After all, Node-RED itself DOES already contain a lot of details available in the logs if you turn up the level.
At the node runtime level, this might not be too great an overhead if done right.
Better observability of the flows is something I want to look at (along with everything else).
This is why I'm keen to get some interest in contribution to the core rather than doing everything via plugins. Whilst the hooks API does make it easier to do, I suspect there will be more efficient approaches when do in conjunction with the core.
As for the "editor is not a dashboard" argument, I don't think that applies here. This isn't about creating an end user dashboard as you would with the dashboard nodes. This is about having the tools in the editor to help develop your flows.
It would not need to be 100% accurate to be useful. You'd typically sample the metrics data with a configurable frequency that fits the volume of the data or the level of accuracy required.
But would the Node-RED editor be the right place to inspect this information? Have you considered instrumenting the core with something like https://opentelemetry.io? This way the heavy lifting of processing/analysing the data could be handled in whatever compatible system/service the user decides to use (or not to use).
You might be interested in this post. I've implemented a message tracer with an extra feature to send messages to the debug panel. More details at the package readme.
If this is the case, then have a look at what I did with the introspection msg tracing. I'm using as much inbuilt Node-RED as I can, something that would be nice would be a method for highlighting message in the debug panel. I put something together but it's based on doing CSS changes directly on the divs of the debug panel - not very Node-RED like.
Exactly! This what I'm trying to do but via a plugin because via a plugin it is far simpler to experiment and try things out. The latest version, 0.9.3, I've started using RED.utils.createNodeIcon(...), in combination with treeList(..) widget, the end result is a simple but elegant (IMHO) listing of nodes being called during flow execution:
Plugins are good for this type of prototyping - considering I started three days ago with simple message tracing. I would not have been able to do the same prototyping having to update the NR debugger with each step.
It works surprisingly well - I was monitoring a 50ms loop (reason will remain unknown) and that was generating four messages every 50ms - my tracer and Node-RED editor handled that without an issue.
Having said that, if I then dump every message to the debug panel, then the editor dies, very quickly in fact. But just keeping a count of messages and tracing them in the editor works fine.
EDIT: I'm not advocating doing this for hours, but for a few minutes to check something, then it's fine. Since yes, the websocket communication is flooded but a backlog does not seem to be created. But as always, your mileage will vary.
I’d go even further and say that the editor is not just an editor when you are bug tracing and putting debug nodes everywhere (manual observability).
So I too think it’s a question of framing, and I think it would be helpful for even just the «editing» if for example the user could turn on a setting for having the famous Node-RED wires crudely change coulour (intensity) depending on activity (resource utilisation). And then I’m not talking about a misleading animation like in some flow editors.
There’s no doubt that this would help the user’s understanding of the flow in what is a visual flow editor, while not being too much of an unecessary resource hog or just too much bells and whistles for others.
