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