Hi Kai and thanks for the quick reply! The main reason I ask is that we need some features currently not available in Graylog2, such as:
* more flexible alert conditions (per stream) here we would like to check for field contents (and not just a single field) * enhanced drools support currently drools rule matching is only performed at the very beginning, we would like to have drools per stream or other criteria Our use case: We have a general drools rule, where we do some enrichment (joining several drools streams). The rule consequence will then add fields to the messages for post processing. Once the stream is assigned we have stream specific drools rules (and static threshold matchers) that will pick up on the added fields of the previous match and will perform final processing such as custom output routing etc. This is the reason why need to know the priorities so we can inject our filters accordingly. Another good feature would be to have some kind of *context* so that filters/plugins can communicate with each other (and for example rely on the same fact database for rule matching). If you need further information, please let me know and I can do some kind of more structured write-up for this. Regards, Ronald On 25 Jan 2015, at 12:40, "Kay R?pke" <[email protected]<mailto:[email protected]>> wrote: Hi! Right now you can rely on this, and you are free to use any number you want. In case of collisions the filter's names are being use to tie break in a deterministic order. In the future we are very likely to revamp this part of the code, but that will either still support (then) legacy MessageFilter plugins or support a better way of dealing with the extensibility. We would appreciate feedback on what's missing so we can plan accordingly. For the next few months however this will probably not change and certainly not within the 1.x series. Best, Kay On Jan 25, 2015 10:20 AM, "Ronald Rink (d-fens GmbH)" <[email protected]<mailto:[email protected]>> wrote: Hi, currently the filters ExtractorFilter, StaticFieldFilter and StreamMatcherFilter have defined priority hard coded in their source code. Is this something that is fix and can be relied upon or is this *opaque* and subject to change? The reason I ask for is that we implement filters that depend upon the StreamMatcherFilter has already run and thus a message is already assigned to a stream. So is it safe to specify a priority over *40* ? Are there any plans to have an option in graylog2.conf to specify the priority of these filters? Thanks for your reply! Regards, Ronald -- You received this message because you are subscribed to the Google Groups "graylog2" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:graylog2%[email protected]>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups "graylog2" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/graylog2/nL4LZG3KUkk/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "graylog2" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
