[syslog-ng] using correlation to filter out some messages ?

Martin Holste mcholste at gmail.com
Fri Jan 14 20:18:16 CET 2011


Ok, I'm with you so far on this.  So when this is run, there will be
two messages, one which has a tag of "dropthis" and gets filtered out
by the f_drop, and the other proceeds normally?  If that's correct,
then I don't understand the strategy but I do understand the
configuration.

On Fri, Jan 14, 2011 at 5:44 AM, Balazs Scheidler <bazsi at balabit.hu> wrote:
> On Thu, 2011-01-13 at 19:44 -0600, Martin Holste wrote:
>> > Sorry for not answering any sooner, but as this post shows I usually
>> > process my backlog every now-and-then. Matthew and Martin usually helps
>> > a lot of people encountering this stuff, but certainly they may not be
>> > able to help everyone :)
>> >
>>
>> Ha, this one is well beyond me--I'm also struggling with the correlation stuff.
>>
>> >  Then, create a timeout action (e.g. <action trigger="timeout">, which should
>> >  generate a message identical to the matched one, but this time
>> >  without the tag which indicates that the message should be dropped.
>> >
>>
>> This is where you're losing me.  Can you provide a working example of
>> the whole thing?
>
> something like this:
>
> <action trigger="timeout">
>  <message>
>    <values>
>      <!-- HOST, PROGRAM, PID are filled automatically based on the current message -->
>      <value name="MESSAGE">${MSG}@1</value>
>    </values>
>  </message>
> </action>
>
> while the body of the rule contains this:
>
> <tags>
>  <tag>dropthis</tag>
> <tags>
>
> This tag can then be used to drop messages by a syslog-ng
> filter, something like this:
>
> filter f_drop { tags("dropthis"); };
>
> parser p_db { db-parser(); };
>
> log { parser(p_db);
>        log { filter(f_drop); flags(final); };
>        log { destination(normal-destination); };
> };
>
> Or an equivalent.
>
> When db-parser() matches a rule, it does the following:
>  1) process the current message (matching the rule) by adding name-value pairs and tags as described by the rule
>  2) possibly create new messages based on actions associated with the rule.
>
> The body of the rule (e.g. the contents inside the main <rule></rule> tag)
> are applied to the current message. Actions are processed when their
> specified trigger is hit, e.g. either on timeout (trigger="timeout") or
> at the same time the rule is matched (trigger="match")
>
> This way a single rule match can in theory result in several messages
> to be emitted.
>  1) the message coming in and triggering the rule
>  2) all the messages generated by associated actions.
>
>
>
> --
> Bazsi
>
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.campin.net/syslog-ng/faq.html
>
>


More information about the syslog-ng mailing list