On Tue, 16 Feb 2016, David Lang wrote:
On Wed, 17 Feb 2016, Damiano Verzulli wrote:
There are a log of possible things going on here, it's not going to
be
possible to guess which are the cause until we see the config.
I already posted it in response to Rainer's request
I must have missed it. Please post again.
Here is the message the OP was referring, directly from the ML archives:
http://lists.adiscon.net/pipermail/rsyslog/2016-February/042046.html
In the middle, it reports several config infos.
Ok, this config is using imjournal, which is what systemd recommends, but not
what rsyslog recommends. Part of the reason why we don't recommend this
approach is that this means that all logs go first into the systemd journal,
and then a polling process (the imjournal process) has to query systemd
asking if there are any new messages, and if so, then ask for the new
messages. This process is inherenly a problem for someone looking for low
latency like the OP is.
This module is documented at
http://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html and
in that documentation, I don't see anything that lets you adjust it to poll
more aggressively.
RedHat has opted for this as their default, argue with them over it (please,
we disagree with their choice :-)
There is a different approach that you can take that will set the systemd
journal to forward the logs to rsyslog (note that this still suffers a
performance hit from the trip through the journal) that's fairly well
documented in the systemd documentation.
And I'm told that there is a way to tell systemd to not have the journal
listen to /dev/log at all, which would allow rsyslog to operate as it
traditionally has. But I don't know how to find this option to point you at
any documentation for it.
Now, it is possible that I am wrong, and the problem isn't the trip through
the journal, but we know that doing so is going to add delays. Try configuing
imuxsock on some other port and configure something to log to it and see what
delay you get there.
Also note that the queue you have setup only affects traffic destined to the
172.31 destination, traffic to the 192.168 destination does not have an
action queue, so any backups or delays on that connection will delay all
messages, including ones written locally. This is one of the places where the
new style config makes it much clearer that the queue only applies to the one
action.
Also, I would setup a template like
$template checktimes,"%timegenerated:::date-unixtimestamp%
%timereported:::date-unixtimestamp%\n"
/var/log/timestamp;checktimes
and look at the difference between when the log was generated (the second
number) and when rsyslog got the message (the first number)
I rotate my logs every minute on my central server and do not see any
significant delays beween when the logs are generated and when they get into the
files.
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.
