On Mon, 7 Oct 2013, Pol Hallen wrote:
throwing away logs when it's queue gets too full, look at thie high
watermark
configuration options for how to do that.
Very very clear! I'm try to calm now... :-O thanks for help :-)
So, what you advice me? Can I continue using this configuration increasing
space of logs on the client? Or is there "best" solution?
Part of the problem is that syslog was written with the idea that logs were
absolutly critical, you would rather have the service be down than have it
running without generating logs.
This is seldom correct nowdays
My recommendation is that when you are designing your logging system, have your
systems send their logs locally to a relay server on the same network. For this
hop you should try to use UDP syslog (so that if there is a problem, the clients
keep going). This won't work if you need encryption even over the local network.
Then, these local syslog relay servers can be where you configure the more
complex stuff, like encryption, queueing to disk when memory is full, and
watermark settings to deal with the case where the disks fill up. You can also
make this local syslog server be a HA pair to make your logging more robust.
As a quick-and-dirty practical matter, if you configure rsyslog to use a disk
assisted queue (so that when memory fills up, it will start using disk space)
you are probably going to be able to keep going so long that you will outlast
any connection outage.
so, on your clients, if you just set a workdirectory and queue filename, you
will probably be in pretty good shape as a practical matter.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
