Ready for merge now. On Thu, Mar 31, 2016 at 12:55 AM, singh.janmejay <[email protected]> wrote: > 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
-- 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.
