Hello.
I've run into a problem while forwarding syslog traffic to another
rsyslog via UDP. The forwarding host is using rsyslog 7.4.6, but this
part of the code is similar in 7.5 and v8.
The host is receiving approximately 100krps, writes them to files, and
forwards along. Each minute, at 13th second of the minute, all omfwd
outputs cease to work. At 43th second, they are resumed for the next
half of a minute. This happens because socket output queue becomes full,
probaly there are some burst of messages around this second each minute.
Increasing core.wmem_default solves that. But I feel that this is just a
workaround.
For me, it looks strange that omfwd action is suspended, when using UDP.
I cannot realize any valid reason for suspending the action for more
than few milliseconds. Why suspend UDP flow at all?
Unfortunalely, rsyslog has action.resumeinterval parameter measured in
seconds, so any value above zero will block traffic for too long. Should
I set action.resumeinterval="0" in this case?
As far as I see from sources, retry code probably will not resend failed
message, because retries are done in a tight loop and socket congestion
will probably exist for some microseconds?
--
Pavel Levshin
_______________________________________________
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.
