Message tracing in Node-RED debugger #69
bartbutenaers
started this conversation in
Design Proposals
Replies: 1 comment
-
Hi This node is totally appreciable although we are noticing it only now. Any plans to improve this further? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey guys,
This discussion is about a proposal I did a few days ago in this discussion on Discourse: to add a checkbox on the node input/output config screen "enable msg tracing". As soon as you activate this feature, Node-RED will start tracing a message that pass through this node input/output. Which means that Node-RED keeps track of how much time the message has spend in all the nodes it has been passing through the flow.
A starting point of this feature could be my node-red-contrib-msg-profiler node. Note that this node is not published on npm yet, since it was mentioned - at my announcement - that it would be better to integrate this functionality in the debugger. The disadvantage is that I haven't received any user feedback, so I have no idea whether the concept is good enough for decent troubleshooting in real life performance issues. I only used it myself to find the root cause of performance issues in one of my ip cam flows.
I will try to explain a bit how my node works.
1. Message hooks
The node makes only use of the onReceive and onSend hooks:
My tracing works like this:
First the user needs to specify one or more initiator nodes. Only when a message passes through such an initiator node, then that message will be traced.
When the message passes such an initiator node, then the
onSend
hook of that node add amsg._msgtracing
field to the message.When the message arrives at another node, the
onReceive
hook will - only when the message has amsg._msgtracing
field - add an entry in themsg._msgtracing.profile
array. That entry contains both the node id and the current timestamp.When the message leaves that node, the
onSend
hook will - only when the message has amsg._msgtracing
field - update the last entry in themsg._msgtracing.profile
array. The hook will estimate how long the message has been spending inside this node, by calculating the difference between the previous (onReceive) timestamp and the current timestamp.Moreover at this point some other statistics are being calculated and added to the
msg._msgtracing
field. Like e.g. the total/min/max/avg size spend in all the nodes. By doing this immediately, themsg._msgtracing
is always up to date. Which means the user can intercept the message everywhere in his flow, to use the (up-to-date) profiling data inside themsg._msgtracing
field.I have been doubting whether I should have used the
postReceive
hook, instead of theonReceive
hook. But I had the impression that the estimated time (which the node has spend inside the node) was more accurate when using theonReceive
hook ...2. Known limitations
The limitations that I am currently aware of (based on my own limited testing) are:
If a node creates an empty output msg from scratch (instead of enriching the original input msg with extra data), then there is no link between that original input message and output message. Which means the profiling/tracing information will be incomplete.
If a node resends the same input message multiple times (without cloning it), then the hook will add the profiling info to the same message instance over and over again. At the end the message will contain N duplicates of similar profiling/tracing information.
3. Integration proposal
Instead of working with initiator nodes, imho it is easier if tracing can be activated in the node input/output config screens (as mentioned above):
Beta Was this translation helpful? Give feedback.
All reactions