I've been playing with 3.2beta1 recently and getting my feet wet with the patterndb support, which I haven't had a chance to work with before. I have a few thoughts regarding the patterndb rule syntax, mostly targeted at making things a little bit easier to work with. - Rule IDs Is there any particular reason why unique IDs were selected as rule identifiers? They're not particularly meaningful to people, and they're hard to talk about. It's much easier to say, "we're suddently seeing lots of matches for ssh-accept-connection" than it is to say, "we're suddenly seeing lots of matches for 4dd5a329-da83-4876-a431-ddcb59c2858c". With the current version of syslog-ng it looks like it's possible to use arbitrary identifiers in place of UUIDs, and that's what I'm doing for my local rulesets. This even makes classification metadata more useful, because .classifier.rule_id=ssh-accept-connection is immediately meaningful, while a UUID is useless unless I go grepping around the database. - Whitespace Log messages tend to be long, which makes them unwieldy in a number of situations. It would be nice if instead of this: <pattern>...some very long log message that makes my life difficult and my patterns hard to read ...</pattern> I could do this: <pattern collapse_whitespace="yes">...some very long log message that has been conveniently wrapped to that it's easier to edit, email, and otherwise work with.</pattern> Specifically, enabling "collapse_whitespace" would transform any sequence of whitespace to a single " ". As proposed here this would be a completely backwords-compatible change because the default behavior would remain the same. - Reusable patterns We use Cisco firewall modules on our network. When these devices log a connection-related message, the source and destination address look something like this: ircs:3610:67.186.94.126/41004 That's: interface:vlan:ip/port Which becomes: @ESTRING:fwsm.src_if::@@NUMBER:fwsm.src_vlan@:@IPv4:fwsm.src_ip@/@NUMBER:fwsm.src_port@ When this occurs throughout the ruleset, and multiple times within a single message, it really lowers the readability of the rules. I wish there was a way to modularize this so that I could create custom types, something like this: <type name="FWSM_ADDRSPEC"> @ESTRING:iface::@@NUMBER:vlan@:@IPv4:ip@/@NUMBER:fwsm.port@ </type> And then do this: <pattern>Accepted src @FWSM_ADDRSPEC:fwsm.src:@ dst @FWSM_ADDRSPEC:fwsm.dst:@</pattern> And get this: fwsm.src.iface fwsm.src.ip fwsm.src.port Etc. Anyway, that's all for now.