oops, hit enter accidently...
On Mon, May 5, 2014 at 12:18 PM, Rainer Gerhards <[email protected]>wrote: > > On Mon, May 5, 2014 at 11:42 AM, Bill MacAllister <[email protected]>wrote: > >> >> >> --On Sunday, May 04, 2014 08:34:12 PM -0700 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) >>> >> >> Ah, I understand now. You can specify a queue.type for any action, >> but for file actions it is ignored and set to direct. >> >> > Not 100% correct. A file action is like any other action, and so the queue > type is applied. However, it doesn't make sense to use a queue for omfile, > because it is fast and extremely reliable (except if you write over the > network, e.g. NFS). > > You define the > ... the queue on those actions that may block -- the forwarder in this sample. If the forwarder uses a direct queue, and omfile would use a linkedlist queue, omfile would still be blocked because the main queue would be blocked by the forwarder. Just to clarify. Rainer > >> 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) >>> >> >> Thanks for that. I didn't realize I could do that. Nice. >> >> I'm also not seeing the entries I would expect for the queue for the >>> remote output >>> >>> i'm wondering if you have the queue working properly. you define a >>> lot of queue parameters, but i don't see anywhere where you actually >>> set the queue type. >>> >>> check the starup messages to see if there are any errors (output >>> from starting rsyslog manually, and if nothing is there, try looking >>> at the output with -dn and see what is has to say about that >>> action/queue >>> >> >> It was starting up cleanly, but you are right I had the queue setup >> incorrectly. I had two problems. Well, I made two changes and it >> started working. >> >> - Added a $WorkDirectory directive, and created the directory. >> - Added a queue.type="LinkedList' to the defaultRemote action. >> >> Here are the actions that I have defined. >> >> *.emerg action(type="omusrmsg" >> name="emerg" >> users="root") >> *.debug action(type="omfile" >> name="defaultLocal" >> >> file="/var/log/messages" >> template="FileFormat") >> *.debug action(type="omfwd" >> name="defaultRemote" >> >> Target="logsink-dev.stanford.edu" >> Port="10514" >> Protocol="tcp" >> queue.Type="LinkedList" >> queue.FileName="defaultRemote" >> >> queue.size="4000000" >> queue.HighWaterMark="100000" >> queue.LowWaterMark="10000" >> queue.MaxDiskSpace="2g" >> queue.WorkerThreads="10" >> queue.TimeoutEnqueue="120000" >> action.ResumeRetryCount="-1" >> template="ForwardFormat") >> *.err action(type="omfile" >> name="console" >> file="/dev/console") >> >> >> 4. The 'tail -f' on the local system records the first of the test >>>> messages from the test and then stalls. >>>> >>>> 2014-05-04T19:06:58.861431-07:00 zoot-vm1 whm: This is Testmessage #0 >>>> >>> >>> we would want to see the pstats output at this point >>> >> >> You and me both. The output stalled on the local system with my initial >> broken configuration. >> >> Thanks for your help, >> >> >> Bill >> >> -- >> >> Bill MacAllister >> Systems Programmer, Stanford University >> >> _______________________________________________ >> 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. >> > > _______________________________________________ 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.
