Hi, As I wrote earlier I'm in the process of redesigning syslog-ng internals, and some log statement flags are way more difficult to implement than with the previous model. These are: "final" -- I see the merit here, and even though it's more difficult to implement, it's worth it "fallback" -- as I see this can perfectly be substituted by a series of lost statement each with "final" flag. Using the final flag is also faster, as syslog-ng does not have to evaluate filters. What do you think? Does anyone use fallback in a way that is not possible using final? If you need more information on the flags above, it is described in the documentation: http://www.balabit.com/dl/html/syslog-ng-admin-guide_en.html/ch08s03.html -- Bazsi
On Feb 8, 2008 6:27 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:
As I wrote earlier I'm in the process of redesigning syslog-ng internals, and some log statement flags are way more difficult to implement than with the previous model.
These are: "final" -- I see the merit here, and even though it's more difficult to implement, it's worth it
We use ' flags(final);' all over the place, along with a few 'flags(catchall);' statements. I can see where fallback could be useful, yet never had a reason to use it in production. Kevin
Balazs Scheidler wrote:
Hi,
As I wrote earlier I'm in the process of redesigning syslog-ng internals, and some log statement flags are way more difficult to implement than with the previous model.
"fallback" -- as I see this can perfectly be substituted by a series of lost statement each with "final" flag.
Using the final flag is also faster, as syslog-ng does not have to evaluate filters.
What do you think? Does anyone use fallback in a way that is not possible using final?
Technically speaking, fallback *can* always be implimented using a combonation of final flags and a non-final statement at the end, but it requires carefull attention to detail, and places a dependency on the order of the log statements in the configuration file. I don't like having a dependency on the order of the log statements. I would favor an easy to maintain configuration file over a challenge during design of the code. We have already ended up with configurations that dropped some messages, and without the fallback, it would be very difficult to track down these events.
On Fri, 2008-02-08 at 17:17 -0800, Evan Rempel wrote:
Balazs Scheidler wrote:
Hi,
As I wrote earlier I'm in the process of redesigning syslog-ng internals, and some log statement flags are way more difficult to implement than with the previous model.
"fallback" -- as I see this can perfectly be substituted by a series of lost statement each with "final" flag.
Using the final flag is also faster, as syslog-ng does not have to evaluate filters.
What do you think? Does anyone use fallback in a way that is not possible using final?
Technically speaking, fallback *can* always be implimented using a combonation of final flags and a non-final statement at the end, but it requires carefull attention to detail, and places a dependency on the order of the log statements in the configuration file. I don't like having a dependency on the order of the log statements.
I would favor an easy to maintain configuration file over a challenge during design of the code. We have already ended up with configurations that dropped some messages, and without the fallback, it would be very difficult to track down these events.
In the meanwhile I came up with a solution that'll work for both final and fallback, so as it seems no reason to drop it. :) -- Bazsi
participants (3)
-
Balazs Scheidler
-
Evan Rempel
-
K K