Well it should use the disk. Maybe you should post your full config ;). New events are discarded. For existing ones it would be very complicated.
Sent from phone, thus brief. Am 20.02.2015 08:04 schrieb "Stoyan Nikolov" <[email protected]>: > Hi! > > Well, yes, eventually I went ahead and added a discard mark and severity > parameters to start flushing events out. > > The problem is that Initially I believed that the queue size would be > dynamic and it will grow as long as queue.MaxDiskSpace is not reached, at > which point it will start discarding events (automagically). Clearly that > is a misunderstanding on my side. > > One more question: when events are being discarded, what is the default > behavior regarding age of the events? Are older events discarded first or > is it the other way around? Is there a way to manipulate that in some way? > > Regards, > Stoyan > > > > > > > On Fri, Feb 20, 2015 at 8:56 AM, Rainer Gerhards <[email protected] > > > wrote: > > > Think about it: what should rsyslog do if the queue is full? > > > > Sent from phone, thus brief. > > Am 20.02.2015 05:54 schrieb "Stoyan Nikolov" <[email protected] > >: > > > > > Thanks for the suggestion! > > > > > > However, even though I skipped that in my initial mail, I do have a > > > separate queue, not for the ruleset, but for the action itself. > > Processing > > > halts when that queue gets filled up. Will the behaviour change if i > set > > > queue to be for the ruleset instead of the action? > > > > > > Regards, > > > Stoyan > > > On Feb 20, 2015 1:40 AM, "David Lang" <[email protected]> wrote: > > > > > > > On Thu, 19 Feb 2015, Stoyan Nikolov wrote: > > > > > > > > Hi! > > > >> > > > >> > > > >> I am using rsyslog v. 7.6.7. > > > >> > > > >> I am trying to configure rsyslog to send certain events to a remote > > > server > > > >> over relp and stop processing them further. In order to do so, I set > > an > > > if > > > >> condition that, if successful sends events via omrelp. Everything > that > > > >> does > > > >> not match the filter should just go through to the following actions > > for > > > >> processing. I want to ensure that the events eventually end up in > the > > > >> remote server, even if it experiences downtime so i use > > > >> "action.resumeRetryCount="-1"" in my omrelp action. > > > >> > > > >> My config looks something like: > > > >> > > > >> if ($msg isequal "bla") then call ruleset ruleset1 > > > >> > > > >> ruleset(name=ruleset1){ > > > >> action(type="omrelp" .... action.resumeRetryCount="-1") > > > >> stop > > > >> } > > > >> > > > >> action2 > > > >> action3 > > > >> action4 > > > >> > > > >> However, when the omrelp target cannot be reached - this leads to > > > complete > > > >> rsyslog halt, even events that don't match the filter for my omrelp > > > action > > > >> don't get processed. > > > >> > > > >> Is there a way to prevent that? > > > >> > > > >> I want to acheive: > > > >> > > > >> Reliable omrelp logging to a remote server, which may be down for > > > extended > > > >> periods of time - has to be first so that events that are send to > the > > > >> remote server are not logged via the other actions. > > > >> > > > >> Other logging actions shold not be affected if the omrelp server is > > not > > > >> reachable. > > > >> > > > > > > > > you need to setup a queue for the ruleset > > > > > > > > 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. > > > > > > > _______________________________________________ > > > 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. > > > _______________________________________________ > 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.
