[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