There is a work around to this current issue where patterns can be changed to have @ANYSTRING@ at the end. Explicitly doing this, rather than having patterndb do it automatically gives the user the most control/flexibility. Because there is a work around available, I would NOT revert this latest change. If you look at the original bug report https://bugzilla.balabit.com/show_bug.cgi?id=211 it was to use the amount of literal text in the pattern for the order of preference, so I would add this to the patterndb, NOT pdbtool merge, because many people will not use pdbtool merge and the results of a merged and manual pattern database should be consistent. A change request for literal text pattern preference should be added to the TODO list. With regards to "whether the preference over full matches over partial ones should stay as an option", I don't see this as valuable. Using full matches is really just an edge case of longer matches. It does not make sense for the length of a message (rather than the pattern) to influence the order of matching preference. The order of matching needs to be consistent regardless of the log stream input, which is unknown at the time of making the pattern database. Does that make sense? Evan. On 09/26/2015 11:33 AM, Scheidler, Balázs wrote:
Hi,
It is simple to revert to the old behaviour, and maybe we should just do that.
Using the amount of literal text in the pattern as the sort order of specifism is a good idea, this could perhaps be added to pdbtool merge.
The question is whether the preference over full matches over partial ones should stay as an option or be dropped entirely.
What do you think?
On Sep 22, 2015 10:43 PM, "Fabien Wernli" <wernli@in2p3.fr <mailto:wernli@in2p3.fr>> wrote:
Hi Evan,
On Tue, Sep 22, 2015 at 09:49:43AM -0700, Evan Rempel wrote: > I propose that the PatternDB preference be changed from the pattern with the longest MATCH to the pattern with the largest amount of static content.
I fully agree with Evan here: it should work as described in this sentence. That being said, I'm not so sure about the Status quo with 3.7.1. Maybe Balázs can give some more details on the change?
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
This body part will be downloaded on demand.