Consider merging with `winston-syslog` project

[markstos]

While syslogd are rsyslogd are different syslog servers, they speak a common protocol. Thus it seems that winston-syslog could speak to rsyslog servers, while winston-rsyslog2 could speak to a syslog server.

We should consider if the projects could be merged. For example winston-syslog code to check the connection, and if the connection fails, retry the connection several times while queuing the logs until the connection comes back up. We lack that feature. We have the feature to map winston log levels to syslog log levels, but that hasn't landed yet in `winston-syslog'.

[imsky]

Yes, I've been thinking about this, too. It is not immediately obvious why syslogd and rsyslogd can't just be two backends to the same logger.

[markstos]

I found that ain2 explicitly mentions working with both rsyslog and syslog. winston-syslog-ain2 has been built on top it, it should work with both syslog and rsyslog already. ain2 has almost 3,000 downloads/month so I presume it is well tested.

Error handling looks decent in ain2. If there is a problem connecting to the syslog server, it won't lose the error message, but will sending a copy to console.error.

[imsky]

So is there a reason for rsyslog2 to exist then? Why not just move to the ain2 transport?

On May 22, 2015, at 12:11 PM, Mark Stosberg notifications@github.com wrote:

I found that ain2 explicitly mentions working with both rsyslog and syslog. winston-syslog-ain2 has been built on top it, it should work with both syslog and rsyslog already. ain2 has almost 3,000 downloads/month so I presume it is well tested.

Error handling looks decent in ain2. If there is a problem connecting to the syslog server, it won't lose the error message, but will sending a copy to console.error.

— Reply to this email directly or view it on GitHub.

[markstos]

Good question. It's worth trying.

I'm now considering yet another approach, which is to just stream logs to STDOUT and STDERR. When I need to communicate with rsyslog, STDOUT and STDERR can be piped to the logger command, which is installed by default on Ubuntu in the bsdutils package. logger will in turn stream the files to rsyslog for me. Something like this:

 node service.js | logger

If rsyslog isn't needed, such as local development and testing, then we don't pipe to logger.

This addresses all the issues I've seen with syslog solutions in Node.js:

• losing logs when there's a bad connection / lost connection
  • Queuing logs while the network connection is done, but not capping the queue, so memory might fill-up.
  • Opening a new network connection every time a log is written

By contrast, there's very little mess up about writing to STDOUT or STERR (that's just using console.log!), and very little to go wrong with piping to logger.

This blog post makes a good case for this approach:

Logs are Streams, not files .

[imsky]

This is a different point though. I do need an in-app rsyslog transport, since it's unknown whether or not IO will be piped to logger. What I'm wondering is whether it makes sense to deprecate winston-rsyslog entirely since the ain2 transport appears to solve the problem this issue is raising.

[markstos]

It's worth considering. I would compare the feature set, the internals a bit and try it out. If it works well as a replacement, I agree there's no need to have another project.