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 docume

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