Le 15/01/2011 12:41, Balazs Scheidler a écrit :
The aim was to drop the lines unless proved to be part of a real session. It is part of a real session, if:
1) the closure message comes 5 seconds after the first one (that's the correllation timeout) 2) or if the connection request came from a different host from the load balancer.
In effect, it'll hold the connection open/close messages until either of the above conditions will prove that the message can be written out. But in order to do this, we need to drop the 'raw' log message first and reproduce it once we know we have to. Thanks for your explanations.
However, in my case the problem can be simplified, as the load-balancer (a cisco switch) never initiates LDAP connections itself, so the logic can be simplified to: - any initial connection message from the load balancer should be dropped - any connection closure message correlated with an initial connection message from the load balancer should be dropped too The following rules database should be enough for this. I tested it to match first and second messages with pdbtool. However, it still doesn't filter the closure messages, with the following configuration: filter f_ldap { facility(local4); }; filter f_slb_ldap_probe { tags("dropthis"); }; parser p_db { db-parser(); }; log { source(s_sys); parser(p_db); filter(f_ldap); filter(f_slb_ldap_probe); destination(d_drop); flags(final); }; What am I missing ? -- BOFH excuse #24: network packets travelling uphill (use a carrier pigeon)