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