[syslog-ng] Syslog-ng as basic realtime reliable logfile replicator. Possible?

[PÁSZTOR György]

Hi,

"Declan White" <declanw at is.bbc.co.uk> írta 2018-01-29 14:34-kor:
> I'm trying to fit syslog-ng around a basic problem and looking for tips.
> 
> I have log files growing on one machine that I want to follow and reliably replicate to a central machine, so it's effectively a basic 'tail -f' job.
> It seems simple, but as I try and close out the possible error conditions it's getting hairier and hairier.
> 
> e.g. 
> - by default, there is nothing you can make with syslog-ng alone that will not lose data during a network or endpoint outage.
> - transporting metadata can tell you which file the data is from, but not where in the file it's from, so you can't really tell if you have duplicate data, or missed data. (The inode number might be handy too)
> - behaviour around input file truncation is fuzzy. That a truncation has occured might be useful metadata to send (if you're looking for people fiddling logs).
> - It doesn't seem to be able to encode binary/NULs in the logs, so it cannot relay data from 'untrusted' application logs?
> - Not sure what it does with very long lines. Loses data?
> 
> I'm not necessarily looking to get syslog-ng to recreate the file exactly, just to send enough information to allow something else to work out the full order of events.
> Googling around to see how others solve this problem, I see people doing infinite rsync loops, or installing large Java beasties, or paying someone else to make it all go away.
> 
> I tried using rsyslog, but it melted down into a screaming puddle of nondeterministic threading.

I don't understand every point what and how you want.
But if you use disk-buffering, rfc5424 syslog protocol, and enrich your log
messages with some useful metadata I think your problem can be solved with
syslog-ng.

Eg. if you want to replicate a file source, you can add the file name and
position to every message into the kv-pair section, while the message
itself remain intact. If you have multi-line messages (like java
stacktrace) it's also doable.
And with the rfc5424 the message size is also not a problem. Just you need
enough ram for buffers and maybe some finetuning if the eps is high enough.

Cheers,
Gyu