On Fri, Oct 25, 2013 at 12:57 PM, David Lang <[email protected]> wrote: > On Fri, 25 Oct 2013, Rainer Gerhards wrote: > > On Fri, Oct 25, 2013 at 11:40 AM, Rainer Gerhards >> <[email protected]>**wrote: >> >> On Fri, Oct 25, 2013 at 10:42 AM, David Lang <[email protected]> wrote: >>> >>> On Fri, 25 Oct 2013, Rainer Gerhards wrote: >>>> >>>> Hi all, >>>> >>>>> >>>>> I thought out the details of what I have on my mind and think the >>>>> solution >>>>> can work and support all known use cases. I've also managed to write it >>>>> down this morning: >>>>> >>>>> http://blog.gerhards.net/2013/****10/a-proposal-for-rsyslog-**<http://blog.gerhards.net/2013/**10/a-proposal-for-rsyslog-**> >>>>> state-variables.html<http://**blog.gerhards.net/2013/10/a-** >>>>> proposal-for-rsyslog-state-**variables.html<http://blog.gerhards.net/2013/10/a-proposal-for-rsyslog-state-variables.html> >>>>> > >>>>> >>>>> >>>>> I would appreciate if you could check it and see how the spec can be >>>>> technically broken or identify use cases which it will not be able to >>>>> handle. >>>>> >>>>> >>>> >>>> One case I don't think it can handle is the current work that mmcount is >>>> doing. >>>> >>>> >>>> I have now reviewed what it is doing, including the sample conf that >> came >> with the patch. >> >> >> As I understand mmcount, it creates a counter for each appname that it >>> >>>> sees, and uses that to count how many times that appname has been seen. >>>> >>>> >>>> yes, but it does more. It keeps these counts internally and just >> returns a >> single variable that matches the *current* count. >> >> So it is a very specific solution, not something that you can mimic with a >> generic state (or global) variable system easily - requires support logic >> or further indirection capabilities. >> >> >> the fact that you can use $/a!b lets you have the variables without >>> having >>> >>>> the conflict with anything else, >>>> >>>> but you end up with no way to know what variables exist >>>> >>>> you can't output the entire set of counts without being able to use $/a >>>> >>>> you can't even lookup the count for the current message's appname >>>> without >>>> being able to use domething like $a/{$appname} >>>> >>>> >>>> you are right, that use case breaks. Thanks! I'll review mmcount in >>> more >>> depth now and see how it is actually used. >>> >>> >>> So I don't think this is one of the "usual" use cases, but instead a >> highly >> complex one which would require custom logic even if global variables had >> worked the way you'd usually expect. In other words: no show stopper. >> >> >> The ability to support subtrees can be added, but will be relatively >>> expensive. >>> >>> >>> Do we actually need subtree access? >> > > If we are not trying to depriciate mmcount, then we can probably get away > without it. > > However, as you say, mmcount is a very specific solution. I think the more > general capability would be useful, people frequently want counts on more > than one thing the fact that we now have mmcount (per appname) and > mmsequence (overall count) is an example of this, and I expect that people > will want to have individualized counters on more things (source hosts as > well as appnames for a trivial example), so I think a more generalized > counter capability is a good idea. >
I think mmcount is a very specific solution, and it's main use inside the source tree is to provide an example of how things can be done. We can always add functions to support the rest, but these are feature requests. I think that what mmsequence offers should most probably be available directly (I still thik I don't merge mmsequence, though, as this would open up a new legacy together with a new way to do the same thing - doesn't make much sense to me). Rainer _______________________________________________ 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.
