On Mon, Oct 03, 2005 at 11:40:27AM -0400, Brian Akins wrote:
> Akins, Brian wrote:
>
> >CustomLog mysql://something common env=images
> >CustomLog file:///logs/my.log combined
> >CustomLog spread://somegroup refere
> >CustomLog buffer:///logs/other.log common
I've been looking more at this, and I'm kind of confused as to what the
aim is here. The line;
"CustomLog mysql://something common env=images"
doesn't make a lot of sense to me. The "common" LogFormat is
line-oriented, but a database-driven logformat should be anything but
line-oriented. If it's to be of any real use it should have its own
schema and so on, each nugget of log information would probably be its
own field within a record, defined by a table, and so on.
I think there's a lot more to think about, and I think these kind of
changes to CustomLog may hint at a need for slightly wider-ranging
changes, including to LogFormat. Or maybe strings will do, would we be
happy to see;
LogFormat "INSERT INTO foo VALUES ('%h', '%l');" foo-sql
But in order to save overhead, this would require some intelligence, it
would not make much sense for the pluggable logger to re-parse this
string everytime, to figure out what it should be doing. And where does
it get its database, username and host information from? Do we require
per-provider directives? Do we hack the format more to get them in
somehow?
And after all of this, what if any, are the compelling reasons to
implement this in httpd at all? Why can't all of this be moved into
piped loggers? Why can't they just parse the logs as they get them and
do whatever whoever wants with it after that? After all, many people use
"logger" to log to syslog. The whole mod_log_spread architecture with
two netcat commands, and that can even be done with privilege
seperation, which an in-httpd module never could.
I can understand that it is desirable to have non-blocking logging, but
there are means to deal with this, I've been testing some buffered (on
the piped logger side) piped logging that is I think more than good
enough in that regard. I can also understand that it's desirable to have
reliable logs from a httpd crash, or to guard against a piped logger
crash - but these are a question of code quality (of the piped logger)
more than anything else.
On ftp.heanet.ie, we've been using piped loggers forever, our logs are
damn busy, and we've seen our share of crashes, and these issues just
never arise for us.
What am I not getting?
--
Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
