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. -- 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.
