Wish: update docs to compare to native le_node/bunyan integration

[markstos]

The le_node features built-in bunyan integration with syntax that looks somewhat similar to what this module offers. It would be helpful if the README were updated to clarify what the benefit of using this module us, compared to using le_node directly.

[nemtsov]

I haven't used this module (or logentries) for a while now and not really sure if le_node covers everything that this module does. If you're interested, I'll merge a pull-request with a comparison of the two.

[markstos]

I'm not sure myself so far. I'm currently using "Option C": I have bunyan log to STDOUT, which is then piped to the logger client for syslog. Then rsyslog ships the logs to Logentries for me. This way I don't have to worry about the complications that come with logging directly over the network, like dealing with latency or a queuing design of Logentries has an outage.

I was asking as I was researcing possibly trying the direct-logging approach and was considering both node-bunyan-logentries and le_node and wasn't clear what the differences were.

[nemtsov]

I prefer that approach too. As your implementation, my apps (which don't use this lib) follow the Twelve-Factor App in that they log to stdout and allow the execution environment to control where that stream is delivered.

[markstos]

Logging to STDOUT is also the approach that systemd and some container systems are adopting as well.

When I first looked at log-over-the-network loggers for Node.js, like Logentries clients, I found several shared a common design flaw. They expected the remote site to always be available and responsive. If it wasn't logs could be lost or might accumulate in memory with no upper bound until memory was exhausted.

It's much simpler to let a logging specialist like rsyslog handle that and keep that complexity out of an app.