Have opened a PR for this. Will fold it with other changes in the same area. Here is the PR: https://github.com/rsyslog/rsyslog/pull/931 (not ready for merge yet)
On Wed, Mar 30, 2016 at 8:01 AM, singh.janmejay <[email protected]> wrote: > Cool, I'll make dyn-stats bucket resettable flag the only thing that > controls resetting of its accumulators. It will or won't reset regardless of > impstats reset flag value. > > This is again changing behavior from previous release but is a fairly minor > thing, so we'll just document it and not worry about backward compatibility > of its behavior. > > On Mar 30, 2016 2:55 AM, "David Lang" <[email protected]> wrote: >> >> On Wed, 30 Mar 2016, singh.janmejay wrote: >> >>> Metric owner is the subsystem (action is a perfect example). End-user is >>> author of the config. >> >> >> Except that dyn_stats doen't exist except in the config, so it's the >> "End-user" who sets everything about them. >> >>> In this case ideal situation would be to let action decide which of its >>> metrics are resettable, and let end-user decide which of the resettable >>> metric accumulators(subset of all metrics) do they actually want to >>> reset. >> >> >> I disagree, the module author should not be deciding if something is >> resettable or not. >> >> The module author is either reporting the current state of something (like >> queue length) where there is no resetting, or they are reporting the state >> of a counter (number of messages processed), and it should be up to the >> config author if they want to reset this every reporting period or not. >> >>> In case of dyn-stats, end-user is metric-owner. >>> >>> So we should probably disassociate from impstats reset flag and let >>> bucket-level resettable flag be the only way to control it. >>> >>> That is what you expected the behavior would be, right? So it's more >>> intuitive too. >>> >>> Should we do this? >> >> >> I think so. >> >>> For static counters though, the problem still remains. If you want to >>> reset >>> omkafka resettable counters, but don't want resetting for imudp >>> resettable >>> counters, as of now we have no way to configure it like that. >> >> >> Well, I see that as a legacy interface, so I don't think we need to worry >> about changing that. >> >> Monitoring systems are almost always able to handle counters and convert >> them to rate-of-change. >> >> resetting a counter is always racy with updates. >> >> If a monitoring system is looking at the stats, you almost always want >> them to be non-reset counters. It's only if a person is looking at them that >> you want to show the delta since the last report in the output. >> >> David Lang >> >>> On Mar 30, 2016 2:06 AM, "David Lang" <[email protected]> wrote: >>> >>>> On Wed, 30 Mar 2016, singh.janmejay wrote: >>>> >>>> The problem is, pstats level control is an all or nothing kind of >>>>> >>>>> arrangement. >>>>> >>>>> Ideal setup would be to let metric-owner decide if metric should be >>>>> resettable or not(which allows choosing if its a guage or not) and >>>>> then let end-user choose if they really want to reset each resettable >>>>> metric(counter) (or do they want it as a perpetual counter). >>>>> >>>> >>>> there is only one entity in control of the rsyslog.conf file, how do you >>>> get to 'metric-owner' vs 'end-user'? >>>> >>>> David Lang >>>> >>>> In our case, the end-user control is very coarse-grained, where one >>>>> >>>>> can either get all counters as perpetual or all as resetting. >>>>> >>>>> On Wed, Mar 30, 2016 at 1:41 AM, David Lang <[email protected]> wrote: >>>>> >>>>>> On Wed, 30 Mar 2016, singh.janmejay wrote: >>>>>> >>>>>> Consider a queue-size, its not really a counter, its a guage. It will >>>>>>> >>>>>>> provide point-in-time value of size of the queue. Resetting such a >>>>>>> value will make no sense. Some static metrics we report are guages >>>>>>> (so >>>>>>> subsystem supporting the metric must identify it to be resettable or >>>>>>> not). >>>>>>> >>>>>> >>>>>> >>>>>> but that won't work well with the current policy. >>>>>> >>>>>> you can't have anything as a gauge unless you eliminate the possiblity >>>>>> for >>>>>> any of the pstats data to be gauges. >>>>>> >>>>>> If pstats doesn't reset values, then dyn_stats can't implement gauges. >>>>>> If >>>>>> pststs does reset values, you have turned a lot of things that >>>>>> probably >>>>>> shouldn't reset into gauges. >>>>>> >>>>>> it would make far more sense to define this purely on a per-stats >>>>>> basis. >>>>>> >>>>>> pstats has some items that are always gauges (size/maxsize/etc) and >>>>>> other >>>>>> items that are allowed to be treated as gauges or as counters. >>>>>> >>>>>> In my case, I don't want to reset those things (submitted/enqueued) >>>>>> that >>>>>> can >>>>>> be counters, but that prevents me from having dyn_stats items that are >>>>>> gauges. >>>>>> >>>>>> David Lang >>>>>> >>>>>> >>>>>> Yes, restart is a problem. But restarts are really in-frequent enough >>>>>>> >>>>>>> to not matter. When they do happen, dx/dt chart shows a big dip, but >>>>>>> people still do track perpetual counters. >>>>>>> >>>>>>> Actually its only dyn_inc (we don't have a dyn_dec). But as we go >>>>>>> forward, we may expose capability to support guages and may >>>>>>> manipulate >>>>>>> it with dyn_inc and dyn_dec. >>>>>>> >>>>>>> Resettable flag in dyn-stats bucket does the same thing as >>>>>>> resettable-flag in statsobj static-counter. >>>>>>> >>>>>>> On Tue, Mar 29, 2016 at 3:13 AM, David Lang <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Tue, 29 Mar 2016, singh.janmejay wrote: >>>>>>>> >>>>>>>> Well, from counter pov, some counters by nature need to be >>>>>>>> resettable, >>>>>>>>> >>>>>>>>> some are actually guages (so resetting makes little sense) and some >>>>>>>>> are perpetual (so again resetting is not the right thing to do). >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> can you explain the different categories better? I don't see how any >>>>>>>> stats >>>>>>>> can be 'by nature' one form or another, since it's possible to >>>>>>>> convert >>>>>>>> the >>>>>>>> data from one form to another. >>>>>>>> >>>>>>>> The idea of perpetual counters doesn't work if the contents of the >>>>>>>> counters >>>>>>>> are lost at restart. >>>>>>>> >>>>>>>> It could be that I didn't read the documentation well enough and >>>>>>>> missed >>>>>>>> references to ways to manipulate them besides dyn_inc and dyn_dec >>>>>>>> >>>>>>>> David Lang >>>>>>>> >>>>>>>> >>>>>>>> A global control needs to be at impstats level because some users >>>>>>>> may >>>>>>>>> >>>>>>>>> want to access data in rate-of-change (dx/dt) form rather than >>>>>>>>> absolute value form (it can be derived by adding up the numbers and >>>>>>>>> studying the slope, but its prone to error when some messages are >>>>>>>>> dropped etc). So user needs to have a say in how counters should be >>>>>>>>> reported, should they be reset or not. >>>>>>>>> >>>>>>>>> Same goes for dyn-stats. User may want a perpetual counter for one >>>>>>>>> dyn-stats bucket (regardless of other buckets being configured to >>>>>>>>> reset), so its important to allow a particular bucket to be >>>>>>>>> configured >>>>>>>>> as non-resetting. >>>>>>>>> >>>>>>>>> However, if user chooses to view all the counters in cumulative >>>>>>>>> form, >>>>>>>>> the same config that works for static-counters should work for >>>>>>>>> dyn-stats counters too (so impstats flag is relevant as well). >>>>>>>>> >>>>>>>>> And'ing is necessary because it doesn't make sense to reset a >>>>>>>>> by-nature non-resettable counter. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 29, 2016 at 12:25 AM, David Lang <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What is the thinking in having two switches that get ANDed >>>>>>>>>> together >>>>>>>>>> for >>>>>>>>>> resetting things? I could see two independent controls, or I could >>>>>>>>>> see >>>>>>>>>> the >>>>>>>>>> pstats setting controlling everything, but I don't understand two >>>>>>>>>> getting >>>>>>>>>> ANDed together. >>>>>>>>>> >>>>>>>>>> David Lang >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, 29 Mar 2016, singh.janmejay wrote: >>>>>>>>>> >>>>>>>>>> Will add this to the documentation when I touch it for >>>>>>>>>>> >>>>>>>>>>> output-restructuring. >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 29, 2016 at 12:11 AM, David Lang <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ahh, that's not at all clear from the documentation. >>>>>>>>>>>> >>>>>>>>>>>> I turned off resetting the counters at the pstats level because >>>>>>>>>>>> I >>>>>>>>>>>> was >>>>>>>>>>>> getting soem errors/coredumps from them (quite a few months ago, >>>>>>>>>>>> so >>>>>>>>>>>> it >>>>>>>>>>>> may >>>>>>>>>>>> be solved now) I'm currently getting >100 lines of pstats output >>>>>>>>>>>> now, >>>>>>>>>>>> before >>>>>>>>>>>> I add dyn_stats to things. >>>>>>>>>>>> >>>>>>>>>>>> I'll wait for the restructuring of the dyn_stats output and the >>>>>>>>>>>> new >>>>>>>>>>>> foreach >>>>>>>>>>>> and then try again. >>>>>>>>>>>> >>>>>>>>>>>> David Lang >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 28 Mar 2016, singh.janmejay wrote: >>>>>>>>>>>> >>>>>>>>>>>> Date: Mon, 28 Mar 2016 23:59:46 +0530 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> From: singh.janmejay <[email protected]> >>>>>>>>>>>>> Reply-To: rsyslog-users <[email protected]> >>>>>>>>>>>>> To: rsyslog-users <[email protected]> >>>>>>>>>>>>> Subject: Re: [rsyslog] another dyn_stats question >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry, I meant and'ed not or'ed. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 28, 2016 at 11:02 PM, singh.janmejay >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> No, this reset mechanism is no different than the mechanism >>>>>>>>>>>>>> that >>>>>>>>>>>>>> static-counters use. If you turn it off at impstats level, it >>>>>>>>>>>>>> won't >>>>>>>>>>>>>> reset. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This flag basically sets CTR_FLAG_RESETTABLE (statsobj.h). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Its or'ed with stats-reporter's choice of resetting or not in >>>>>>>>>>>>>> this >>>>>>>>>>>>>> way: (bResetCtrs && (pCtr->flags & CTR_FLAG_RESETTABLE)), >>>>>>>>>>>>>> where >>>>>>>>>>>>>> bResetCtrs comes from that boolean param in impstats. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 28, 2016 at 9:58 PM, David Lang <[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the first one should not be resetting, but the rest should >>>>>>>>>>>>>>> be, >>>>>>>>>>>>>>> correct? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David Lang >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> dyn_stats(name="message_framing" resettable="off" >>>>>>>>>>>>>>> maxCardinality="3000" >>>>>>>>>>>>>>> unusedMetricLife="1200") >>>>>>>>>>>>>>> dyn_stats(name="msgs_per_host" resettable="on" >>>>>>>>>>>>>>> maxCardinality="3000" >>>>>>>>>>>>>>> unusedMetricLife="1200") >>>>>>>>>>>>>>> dyn_stats(name="msgs_per_edge_relay" resettable="on" >>>>>>>>>>>>>>> maxCardinality="3000" >>>>>>>>>>>>>>> unusedMetricLife="1200") >>>>>>>>>>>>>>> dyn_stats(name="msgs_per_core_relay" resettable="on" >>>>>>>>>>>>>>> maxCardinality="3000" >>>>>>>>>>>>>>> unusedMetricLife="1200") >>>>>>>>>>>>>>> dyn_stats(name="msgs_per_program" resettable="on" >>>>>>>>>>>>>>> maxCardinality="3000" >>>>>>>>>>>>>>> unusedMetricLife="1200") >>>>>>>>>>>>>>> dyn_stats(name="msgs_per_tag" resettable="on" >>>>>>>>>>>>>>> maxCardinality="3000" >>>>>>>>>>>>>>> unusedMetricLife="1200") >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, 28 Mar 2016, singh.janmejay wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Date: Mon, 28 Mar 2016 14:37:12 +0530 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From: singh.janmejay <[email protected]> >>>>>>>>>>>>>>>> Reply-To: rsyslog-users <[email protected]> >>>>>>>>>>>>>>>> To: rsyslog-users <[email protected]> >>>>>>>>>>>>>>>> Subject: Re: [rsyslog] another dyn_stats question >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You have resetting turned-off in the config you shared with >>>>>>>>>>>>>>>> me. >>>>>>>>>>>>>>>> That >>>>>>>>>>>>>>>> would prevent resetting of counters. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Mar 25, 2016 at 8:21 PM, singh.janmejay >>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That is not supposed to happen. Although very unlikely, it >>>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>> environment specific bug. Do all dyn-stats tests pass in >>>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>> local >>>>>>>>>>>>>>>>> env? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, are you using something other than impstats to report >>>>>>>>>>>>>>>>> it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mar 25, 2016 7:24 PM, "David Lang" <[email protected]> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> resettable counters don't seem to be resetting for me. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> David Lang >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, 25 Mar 2016, singh.janmejay wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Well, the bug is metric-ttl ends up killing all metric >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> instead >>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> unused-metrics. This works for resettable counters, but >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> non-resettable >>>>>>>>>>>>>>>>>>> counters it kills the accumulation prematurely. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The fix will identify which counters are being used and >>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> kill >>>>>>>>>>>>>>>>>>> them. >>>>>>>>>>>>>>>>>>> So it won't discard accumulated value as long as it is >>>>>>>>>>>>>>>>>>> being >>>>>>>>>>>>>>>>>>> incremented >>>>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>>>> least once within the TTL time. >>>>>>>>>>>>>>>>>>> On Mar 25, 2016 10:53 AM, "David Lang" <[email protected]> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> What I'm seeing is that unless the reset time matches the >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> pstats >>>>>>>>>>>>>>>>>>>> interval, >>>>>>>>>>>>>>>>>>>> the data output doesn't reset each pstats report. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> David Lang >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, 25 Mar 2016, singh.janmejay wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This is a bug. I'll provide the fix on Monday(or in the >>>>>>>>>>>>>>>>>>>> worst >>>>>>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>> few >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> days, in case I don't get a chance to work on this on >>>>>>>>>>>>>>>>>>>>> Monday). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Basically, I was supposed to have a shadow table to >>>>>>>>>>>>>>>>>>>>> mark >>>>>>>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>>>>> counters, >>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> kill unused counters in next run of metric-ttl-cycle >>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>> wasn't >>>>>>>>>>>>>>>>>>>>> present >>>>>>>>>>>>>>>>>>>>> in first cut because I started with resetting counter >>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>> cases >>>>>>>>>>>>>>>>>>>>> first, >>>>>>>>>>>>>>>>>>>>> then somehow this slipped my mind. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mar 25, 2016 4:12 AM, "David Lang" <[email protected]> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> the unusedMetricLife parameter when setting up a stat >>>>>>>>>>>>>>>>>>>>> says >>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> purge an unused stat. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But I've got an example where I create about 5 stats >>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> bucket >>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> what I think I'm seeing is that the stats are >>>>>>>>>>>>>>>>>>>>>> cumulative, >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> reset >>>>>>>>>>>>>>>>>>>>>> each >>>>>>>>>>>>>>>>>>>>>> time they are dumped out, but they get reset every >>>>>>>>>>>>>>>>>>>>>> unusedMetricLife >>>>>>>>>>>>>>>>>>>>>> seconds. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Is this my imagination? or is the behavior not >>>>>>>>>>>>>>>>>>>>>> matching >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> documentation? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Janmejay >>>>>>>>>>>>>> http://codehunk.wordpress.com >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>> >>> _______________________________________________ >>> 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. -- Regards, Janmejay http://codehunk.wordpress.com _______________________________________________ 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.
