[syslog-ng] [patterndb] classification
Balazs Scheidler
bazsi at balabit.hu
Mon Sep 6 10:42:58 CEST 2010
On Fri, 2010-09-03 at 12:24 -0700, Matthew Hall wrote:
> On Fri, Sep 03, 2010 at 09:11:59PM +0200, Balazs Scheidler wrote:
> > Hi,
>
> Hey Bazsi,
>
> > So one email, two questions, feedback appreciated.
>
> Not sure if it's an option but the idea which occurs to me is that you
> are looking for a way of setting and optionally mapping some keys like
> ".classifier.class" or "mhall_special_tag" to some value like "{
> violation, security, ... }".
>
> So my suggestion would be to remap the ".classifier.class" into the tag
> system for compatibility, then extend the tag system to be a hash table.
>
> The nice thing about the hash table would be, you could still support
> existing tags. For example if I tagged a message as "mhall_special_tag",
> in the hash table you could map that:
>
> mhall_special_tag -> PLACEHOLDER
>
> Then for fancier tags like ".classifier.class" you could map that:
>
> .classifier.class -> { violation, security, ... }
>
> Then you could provide some kind of utilities for it to expand what you
> need.
>
> 1) an operation to check if a key is set
> 2) an operation to get the value set for some key
> 3) an operation to check if a value is set
> 4) etc...
>
> Then when I want to break out messages to classifier based dirs, I could
> just call operation (2) to get the value of ".classifier.class".
>
> If I wanted to make a filter that grabbed messages with
> mhall_special_tag set, I could do that using operation (1).
Hmm.. the message itself is already a hashtable (not exactly, but
semantically they are the same).
What you say with the above is that tags should be present/non-present
attributes of the message, right?
The problem I see with this is the namespace, I wouldn't want to collide
tag names with built-in macros or name-value pairs.
--
Bazsi
More information about the syslog-ng
mailing list