Flogger - the advanced logging node!

There certainly are risks when you are writing files, but I don't see making a general rule of this. In the case of the flogger node, the issue starts with the use of msg.filename, which is shared with the core file nodes and perhaps others. As suggested above, the risk of error could be reduced by instead using msg.logfile (or better yet, msg.flogger.logfile) for this property. Also, the node configuration allows the user to define a Log Dir , which can help isolate any damage to that directory. I have used a strategy for overriding defaults that greatly reduces the chance of errors. I name properties that can be overridden as msg.nodename.property, so that for flogger the overrides object might be

msg.flogger = {
   logfile: "mylog.log",
   loglevel: "INFO"
};

The chance of a message accidentally carrying something like this into a flogger node is very small, but the node could still have defaults configured to deal with the case where the message doesn't provide valid parameters.

All perfectly good workarounds. As is the suggestion to use a typedinput which I would argue is slightly more user friendly? (Certainly reduces the need to add change nodes before nodes & therefore simplifies things to some degree)

As @dceejay and I started originally, it is ultimately the DEVs choice...

...we just provide the information, make our requests and hope we provide a good argument with reasoned advice. :slight_smile:

Anyhow, I don't think anyone disagrees that in its prior form (msg.filename overriding the explicit form property) was not the best idea for a couple of reasons.

Btw, that is something I'm going to bear in mind for future. Good Nugget of info.

1 Like

Thank you for the input - it almost got heated a little bit :slight_smile: Here are my decisions:

  • I made the status text date on the node consistent with the local/UTC setting on the node (drmibell)
  • I added a Z designator to the UTC logtime because it makes good sense to know what for the ones reading an unknown logfile (drmibell)
  • Changed back to original behaveour of allowing overriding the filename. To avoid name collisions like Steve talked about, I decided that from now on it should be overridden with msg.logfile. The risk of a name collision with this name is very small. I like drmibell's nested object solution, but I think it's a little too much for the average Joe - my feeling is that it overcomplicates the usage just to protect from extremely rare edge cases.
    I know this goes a little against normal node behavior, but I really feel that it makes sense in this case. It also makes it consistent with the error-level override functionality which I like (drmibell). I feel it's OK because it is well documented in the info section of the node.

Like dceejay says: At the end of the day it is up the author... :grin:

Version 1.1.7 has been committed.

4 Likes

I have just added log rotation to flogger. Now you can specify how big your logfiles can get before they get rotated. Old logfiles can be gzip compressed if you wish.

I also did a lot of refactoring of the code, but that shouldn't affect the functionality. It was getting a little to big and bulky to easily read.

Version 1.2.1 is now committed

2 Likes

Flogger is close to my idea of a perfect logger. Thanks for the contribution!

The only thing I'm wishing it had that I haven't found yet is millisecond granularity.

But how am I to shut the log off??? Short of deleting the node I couldn't get it to stop logging. I thought for sure unwiring it's input would do it but no.

If you don't send a msg, it shouldn't log anything. Are you certain you deployed changes? Are there other flogger instances still operating?

Try searching for flogger in node red (CTRL+f) see if there is more than one

Yes. I'll do it again just to be sure. Hang on...

Something strange is going on. I had it hooked up to a MQTT "read all" node which I'm also testing and the 2nd time I had trouble getting it to start logging. So I restarted NR and still iffy. I copied the flogger node to a live flow and it works as expected, both starting and stopping by disconnecting it's input wires (and Deploy of course).

So I'll retract my original comments... except

Sorry to bother you.

When i use moustache Response payload {{payload}} i get in file [moustache] Response payload [object Object]. What is correct way to render object?
Thanks