using templates

- frequently used matches should be replaced by template, like @IP_ADDRESS@ - no need to specify the lead-in, really, unless we want to also apply to non-syslogd logs

using tags

selection of filters to apply should be dependent on the list of installed packages as well as a set of topical tags. the filters to use are the ones in both sets, so their intersection.

Example:

- tags selected are no-such-user, restart, reconfigure - packages installed are: ssh, postfix

Now only messages relating to any of the three tags and applicable to ssh and postfix will be filtered out.

package versions

I want files like postfix-2.2 and postfix-2.3. Now if postfix 2.2.5 is installed, it uses the file with version less than or equal to, so postfix-2.2 would be used.

context-based rules

- be able to match only if there are e.g. 10+ occurrences of a message (#165449)
- be able to match based on numeric comparisons (e.g. >> 32)

modular design

- logfilter becomes a daemon - subscribers query the daemon with:
- a unique identifier by which to identify the subscriber
- a set of tags to filter
- logfilter uses something like logtail for each subscriber separately - emailing will be done by a daemon subscribing to the main logfilter daemon

a simple editor

One subscriber could be a simple editor that allowed you to select a rule and using the existing templates suggest a regexp, asking the user to interactively refine it while it still matches. Once the rule is finished, it could be saved to a local file and even submitted upstream.