You mentioned not using Winston because you liked to be able to see things on the console. Why not just change the configuration for development to dump to the console and to syslog in production?

Winston actually has a console transport. if that doesn't do what i expect, making a transport that wrote to stdout still seems rather simple.

That was my point. Seeing as Winston has a console transport and syslog support, I'm curious why this wasn't used.

sorry- my intention was to further clarify your point.

Rsyslog has a file source module: imfile( http://www.rsyslog.com/doc/imfile.html). May help in some cases.

Saz

We did look at that: we couldn't figure out a good way to have rsyslog read in the file and then send it remotely to another TCP syslog server. Is that possible?

Also, this let us run on machines which aren't necessarily running rsyslog (you could use it on a Windows machine, provided you had tail installed).

rsyslog's documentation is pretty abysmal, so you can't be faulted for giving up and doing something else. It's actually pretty extensive and useful, the documentation is just awful. Since he's hard at work on v7 I had hoped the documentation would get a little better, since rsyslog is better than syslog-ng in one way (you don't have to pay for local disk buffering), but alas, I'm left hoping.

imfile just injects messages from the tailed file as if they were read from another source. rsyslog just lists a bunch of sources, then dumps all the messages (based on filter) to a destination of your choosing. If, at the end of your configuration you have something like this:

    *.* @@syslog-collector:514

All messages regardless of source will be relayed to syslog-collector port 514. If it's an rsyslog receiving on the other end, try this:

    *.* @@(o,z9)syslog-collector:514

That enables experimental framing that rsyslog can understand, as well as zlib level 9. rsyslog will decode it on the other end just fine. Rainer will tell you to use RELP instead for relaying from rsyslog to rsyslog, but good luck getting it to work on any distribution. A minimal tail-and-forward config would look like this:

    $ModLoad imfile
    $InputFileName /var/log/myapp.log
    $InputFileTag myapp:
    $InputFileStateFile myapp
    $InputFileSeverity 6
    $InputFileFacility local0
    $InputRunFileMonitor

    *.* @@syslog-collector:514

That will tail myapp.log, inject messages as INFO on local0, then forward them to syslog-collector prefixed with "myapp:" on every line. It will not, however, collect the system syslog ... you need to prefix with this for that to happen:

    $ModLoad imuxsock
    $ModLoad imkmsg

Thanks for the excellent write up. Out of curiousitt: Did you investigate other centralized solutions like graylog2 and logstash?

Looked at logstash: we actually liked it, but we already had a syslog server running (for a different project) and we wanted to just reuse that. Plus: we really didn't want to add an additional language dependency to our deployment (logstash is Java-based). We might end up using it for the search functionality, though: our current solution doesn't include search (other than trusty old grep) or any of the nice error/exception detection that we'd like.