Log paths that DON'T stop matching....
It's hard to explain what I want, but here I'll try. A normal log path is thus: log { source(...); filter(...); destination(...); }; ...and when a match occurs (source and filter) then the message is sent to the destination and matching stops. To do what I'd like, with what I've seen so far, is to do something like this: log { source(a); filter(f_ba); destination(c); destination(d); }; log { source(a); filter(f_bb); destination(c); destination(e); }; log { source(a); filter(f_bc); destination(c); destination(f); }; log { source(a); filter(f_bd); destination(c); destination(g); }; log { source(a); filter(f_other); destination(c); }; What I'd like would be something closer to this - taking "passthru" to be an option to NOT stop filtering: log { source(a); filter(f_ba); destination(d); passthru; }; log { source(a); filter(f_bb); destination(e); passthru; }; log { source(a); filter(f_bc); destination(f); passthru; }; log { source(a); filter(f_bd); destination(g); passthru; }; log { source(a); filter(f_other); destination(c); }; This would be very much useful in situations like: log { source(internal); filter(f_crit); destination(pager); } log { source(internal); filter(DEFAULT); destination(mesg); } Or other similar...
A normal log path is thus:
log { source(...); filter(...); destination(...); };
...and when a match occurs (source and filter) then the message is sent to the destination and matching stops. To do what I'd like, with what I've seen so far, is to do something like this:
matching doesn't stop when the first match occurs. a single log message is sent to _all_ matching log statements. The code performing this is in the center.c:do_distribute_log() function. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Balazs Scheidler wrote:
A normal log path is thus:
log { source(...); filter(...); destination(...); };
...and when a match occurs (source and filter) then the message is sent to the destination and matching stops. To do what I'd like, with what I've seen so far, is to do something like this:
matching doesn't stop when the first match occurs. a single log message is sent to _all_ matching log statements. The code performing this is in the center.c:do_distribute_log() function.
Ahhh.... I did reread the documentation, trying to see what it would do specifically. In the documentation, you said that the destinations were "sinks" - a sink doesn't give anything back - especially in computers. The bit-sink never gives anything back :-) I made some changes to syslog-ng.txt and include a patch... --- syslog-ng.txt.orig Mon Jun 4 12:04:10 2001 +++ syslog-ng.txt Mon Jun 4 12:07:31 2001 @@ -105,10 +105,10 @@ Chapter 2. Message paths In syslog-ng a message path (or message route) consist of one or more - sources, one or more filtering rules and one or more destinations - (sinks). A message is entered to syslog-ng in one of its sources, if - that message matches the filtering rules it goes out using one of the - destinations. + sources, one or more filtering rules and one or more destinations. + A message is entered to syslog-ng in one of its sources, if that + message matches the filtering rules it goes out using one of the + destinations. A message may pass through one or more message routes. _________________________________________________________________ Sources @@ -231,8 +231,8 @@ Destinations - A destination is a message sink, where log is sent if filtering rules - match. Similarly to sources, destinations may include several drivers + A destination is a place a message goes, where a log is sent if filtering + rules match. Similarly to sources, destinations may include several drivers which define how messages are dispatched. To declare a destination in the configuration file, you'll need a destination statement, whose syntax is as following:
participants (2)
-
Balazs Scheidler
-
David Douthitt