On Mon, May 5, 2014 at 5:34 AM, David Lang <[email protected]> wrote: > On Sun, 4 May 2014, Bill MacAllister wrote: > > --On Sunday, May 04, 2014 04:03:55 PM -0700 David Lang <[email protected]> >> wrote: >> >> On Sun, 4 May 2014, Bill MacAllister wrote: >>> >>> I need some help understanding how to control queue behaviour. The >>>> goal is to write messages to a file locally and also forward the >>>> messages to a remote rsyslog server. When the remote server is >>>> unavailable I would like message to queue up and be processed when the >>>> server is available again. I have a configuration that works this way >>>> but has the unwanted side-effect that both local and forwarded >>>> messages are being help until the remote server is available again. >>>> Here >>>> is a configuration fragment. >>>> >>>> *.debug action(type="omfile" >>>> file="/var/log/messages" >>>> template="FileFormat") >>>> *.debug action(type="omfwd" >>>> Target="logsink-dev.stanford.edu" >>>> Port="10514" >>>> Protocol="tcp" >>>> queue.FileName="default_queue" >>>> queue.size="4000000" >>>> queue.HighWaterMark="100000" >>>> queue.LowWaterMark="10000" >>>> queue.MaxDiskSpace="2g" >>>> queue.WorkerThreads="10" >>>> queue.TimeoutEnqueue="120000" >>>> action.ResumeRetryCount="-1" >>>> template="ForwardFormat") >>>> >>>> In this configuration there are three queues: the main queue, the >>>> queue for the omfile action and the queue for the omfwd action. >>>> Right? >>>> >>> >>> I don't see any queue for the omfile action, so I think you just >>> have two queues, the main queue and the omfwd queue >>> >> >> Oh, right. During some of my testing I had queue.type="direct", but >> that didn't see to change the behaviour at all. >> > > type=direct is the same as no queue (it's the default) > > > Why does the omfwd queue block the omfile queue? What am I >>>> misunderstanding? >>>> >>> >>> the omfwd queue should only block the main queue if it fills up >>> >>> enable impstats and look at what happens to the queue sizes and >>> activity as you block the TCP connection >>> >> >> Here is my a sample test sequence of steps that I am using. >> >> 1. Here is a tail of syslog output from local system with pstats >> output. >> >> 2014-05-04T19:06:32.206331-07:00 zoot-vm1 rsyslogd-pstats: imuxsock: >> submitted=2122 ratelimit.discarded=0 ratelimit.numratelimiters=2074 >> 2014-05-04T19:06:32.206349-07:00 zoot-vm1 rsyslogd-pstats: action 1: >> processed=0 failed=0 >> 2014-05-04T19:06:32.206353-07:00 zoot-vm1 rsyslogd-pstats: action 2: >> processed=4299 failed=0 >> 2014-05-04T19:06:32.206357-07:00 zoot-vm1 rsyslogd-pstats: action 3: >> processed=4299 failed=0 >> 2014-05-04T19:06:32.206360-07:00 zoot-vm1 rsyslogd-pstats: action 4: >> processed=0 failed=0 >> 2014-05-04T19:06:32.206362-07:00 zoot-vm1 rsyslogd-pstats: pstats: >> processed=2176 failed=0 >> 2014-05-04T19:06:32.206366-07:00 zoot-vm1 rsyslogd-pstats: pstats: >> size=0 enqueued=2176 full=0 discarded.full=0 discarded.nf=0 maxqsize=8 >> 2014-05-04T19:06:32.206368-07:00 zoot-vm1 rsyslogd-pstats: main Q: >> size=7 enqueued=4306 full=0 discarded.full=0 discarded.nf=0 maxqsize=8 >> > > well, we don't know what your full config is, so some guessing is going to > be needed to figure out which action is which, could you name them? (add > name="something" to each action) > > I'm also not seeing the entries I would expect for the queue for the > remote output > > Yeah, the queue.type parameter is not set, so it is default, so it is "direct". Thus we do not have a real queue associated. I agree rsyslog should probably check queue parameters are set, but the queue type not. That's usually an error.
Rainer _______________________________________________ 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.
