On Oct 20, 2010, at 8:59 PM, Martin Holste wrote:
When this occurs throughout the ruleset, and multiple times within a single message, it really lowers the readability of the rules.
I guess for me, readability is pretty far down on the list of features I want poor Bazsi slaving away on, and that's mainly because pdbtool does such a good job of verifying that my patterns match on exactly what I think they do. The other thing is that I think a lot of us are planning on using patternize to do auto pattern generation, and so if all goes to plan, humans won't have to be looking at these very often. On the other hand, I recognize that the easier it is to author rules, the more community contribution there will be.
A few things that IMO would help with this would be: 1) LETTERS - like STRING but ONLY matches on letters 2) Ability to set @ESTRING delimiter to be \t. Right now to get it to work I use vim and Ctrl-V <tab> to insert a literal tab. Using \t doesn't work. 3) Partial match. From my experimentation it seems that to get a match you have to describe the entire message. If it isn't too much a performance hit I'd like to be able to declare a rule to be a partial match. Currently I can define everything up to the match and @ANYSTRING the remainder, but it feels ... off. The way I read the ability that Lars listed, defining a pattern and then re-using it could be very powerful in that it could enable essentially a grammar. For example I have a set of clusters that all use tab delimited logs messages and the first N fields are the same. While it would certainly be more readable to have a "sub-pattern" that I could use to start each rule with that, it would also seem to be more expressive. Then again I am currently working heavily with Apache access logs and looking to see what I can tease out ability-wise with patterndb. Thus my use case may not be that common. Yet. Cheers, Bill