Add fields to custom logger

Hello!

I am trying to improve the quality of our logs and investigating the possibility of custom logger.
I have found it quite useful, but I would like to know if it is possible to add by default fields included in the msg.

I have found that by modifying the log function at line 157 of the file /@node-red/util/lib/log.js I can add more fields to this trace, however I can not retrieve fields from the running msg object.
I would like the msg.id or other fields to appear in the final trace without the need to send the msg object to the logger.

For example, if in the code I write only
node.warn("hello")

the trace that would be generated would be

{ level: 40,
  id: '485b456e.78e4cc',
  type: 'function',
  msg:"hello",
  _alias: '53712995.87dc28',
  z: '7684f2d.6579b0c',
  path: '6b036f2d.4f457/7684f2d.6579b0c',
  timestamp: 1645432467100,
//aditions
  msg_id: "XXXXX",
  msg_otherField:"XXXX"
 }

Could this result be achieved by modifying the /@node-red/util/lib/log.js or some other file?

The calls to the node log functions are entirely independent of what messages are passing through. There is no concept of the 'running msg'.

To capture details of a message, you'd have to passing them in to the call to node.log

Yes, more than the running msg, I was referring to the msg that has triggered the log event.

In the same log.js file at line 217 appears the following code:

    audit: function(msg,req) {
        msg.level = log.AUDIT;
        if (req) {
            msg.user = req.user;
            msg.path = req.path;
            msg.ip = req.ip || (req.headers && req.headers['x-forwarded-for']) || (req.connection && req.connection.remoteAddress) || undefined;
        }
        log.log(msg);
    }

That req property also travels inside msg right? couldn't you access to other properties of the msg to leave them traced?
If not, how can the code retrieve that information?

Thanks!

The audit log is a special case. It only gets used by the runtime to log access to the HTTP Admin API. The req property is passed in explicitly in those calls.

Again, this has nothing to do with messages passing through a flow. The fact the argument is called msg is probably a poor choice on my part.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.