<div dir="ltr">Hmmm - a few questions:<div>- where are the files coming from that you want to follow?</div><div>  Is there another syslog daemon running? Or are you capturing application logs that cannot use kernel logging?</div><div><br></div><div>Syslog-ng can easily use files as sources if that is all you have.</div><div>If you can use syslog-ng as the system log daemon - you can easily write local files *and* forward to a central logger.</div><div><br></div><div>It's pretty easy to have the central syslog server that receives the logs separate them by sending server - I have used HOST_FROM pretty often since it doesn't need name resolution (better for performance) and it will deal with non RFC logs fairly well.</div><div><br></div><div>As far as metadata - I typically put some of this in the filename - like date, host_from, facility, severity, etc.</div><div><br></div><div>Things like file parsing, etc. can usually be dealt with using appropriate mix of flags and parsing/rewrite rules (if necessary).</div><div><br></div><div>Does this help?</div><div><br></div><div>Jim</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 9:34 AM, Declan White <span dir="ltr"><<a href="mailto:declanw@is.bbc.co.uk" target="_blank">declanw@is.bbc.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hullo.<br>
<br>
I'm trying to fit syslog-ng around a basic problem and looking for tips.<br>
<br>
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.<br>
It seems simple, but as I try and close out the possible error conditions it's getting hairier and hairier.<br>
<br>
e.g.<br>
- by default, there is nothing you can make with syslog-ng alone that will not lose data during a network or endpoint outage.<br>
- 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)<br>
- 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).<br>
- It doesn't seem to be able to encode binary/NULs in the logs, so it cannot relay data from 'untrusted' application logs?<br>
- Not sure what it does with very long lines. Loses data?<br>
<br>
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.<br>
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.<br>
<br>
I tried using rsyslog, but it melted down into a screaming puddle of nondeterministic threading.<br>
<br>
Is what I'm attempting really as hard as it seems?<br>
<br>
- D<br>
______________________________<wbr>______________________________<wbr>__________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/<wbr>mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/<wbr>support/documentation/?<wbr>product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/<wbr>syslog-ng-faq</a><br>
<br>
</blockquote></div><br></div>