On Fri, 15 Mar 2019, Joan Tomàs i Buliart wrote:
And how can we put a ‘fire-and-forget’ strategy in place? Using UDP will
work?
Yes, this is why I normally make my first hop be UDP, I'd rather loose logs than
run the risk of stalling the production systems. If you can have a relay on the
same subnet, UDP can be very reliable (it's when the UDP needs to go through a
router/firewall/wan that you start risking loosing traffic)
If we put a queue in place, when the queue will be full, the first Rsyslog
will start to discard logs until Rsyslog 2 becomes available again?
Yes, although there are options to discard messages when the queue gets too
full.
I have been meaning to write an article titled 'how to make your logs
unreliable' for years to go over this stuff. :-)
David Lang
Many thanks for your help,
Tomàs
El dj, 14 març 2019 a les 1:13 David Lang <[email protected]> va escriure:
when machine A is configured to send logs to machine B via TCP, you are
saying
that when machine B isn't processing logs fast enough, you want machine A
to
pause sending the logs (note that you can still loose logs via tcp, you
need to
use relp to avoid loosing logs).
When the omfwd using tcp can't send a log, it waits. To be pedantic, the
worker
thread processing that log waits. Unless there is a queue for that action,
this
means that everything else the worker thread would deliver messages to
will also
be blocked.
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.
