httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: Enhanced error log format for trunk?
Date Tue, 08 Jun 2010 20:56:37 GMT
On Monday 07 June 2010, Rainer Jung wrote:
> On 03.06.2010 16:49, Stefan Fritsch wrote:
> > On Tuesday 01 June 2010, Rainer Jung wrote:
> >> 4) General correlation improvements
> >> 
> >> To be able to correlate error and access log, it would be
> >> helpful to share a common id, e.g. the unique_id, and be able
> >> to log it in both files. The id generated by mod_unique_id
> >> comes too late though (post_read_request). Since it actually
> >> only uses the request timestamp and the connection id of the
> >> request, it could be calculated much earlier.
> > 
> > I have thought about this before, but I wanted to get the
> > per-module loglevel configuration into trunk first.
> > 
> > The log id could be created by the first call to ap_log_rerror.
> > If there has not been an errorlog entry for a request by the
> > time of the log transaction hook, the corresponding field in the
> > access log would just be "-".
> That's an interesting idea, making it pretty trivial to filter
> those lines, that have any error log entries.
> > The function creating the log id could also log some interesting
> > information once per request, instead of logging it for every log
> > line. For example PID/TID, local+remote IP+Port, number of
> > keep-alives on the connection, ...
> Hmmm, but some basics should stay on each line, otherwise it's to
> much hassle collection stuff (or we provide a script). Being able
> to correlate between access and error log is nice, being forced to
> correlate inside the error log to collect the data is not so nice.

The script would be "grep log-id error_log". I fear the useful 
information depends very much on the situation. Logging everything 
makes sure that we have the useful information. But this would 
obviously flood the error log if we do it on every line or even for 
every request. Hence my suggestion to only log it for requests which 
have at least one other error log message logged.

This should be configurable. Either this conditional verbose logging 
or the "some information in every line" style that we have now. And it 
should also be configurable what the "some information" should be.

> Do you already have any code fragments for that?

No, these are only ideas so far. I have thought of following things 
which may be nice to have as error log flags:

- timestamp granularity
- don't log to the error log file (useful for modules using the error 
log hook)
- log some kind of unique id
- do conditional verbose logging as outlined above
- log the name of the module
- always or never log source file name+line number, or make it depend
on the log level like now
- log process/thread id
- log errors that are induced by the client at level error or at level
debug (e.g. file not found, connection closed by client)

Information that may be useful in the conditional verbose logging:
- local/remote port+ip,
- vhost/Host-header
- some way to correlate which requests are on the same connection, 
like a connection id (I think pid/tid are not enough with mpm event, 
but I could be mistaken)
- Referrer-header
- number of keep-alive requests on the connection

That's a lot, but I can think of situations where any of the above 
information would be useful. Actually, for most pieces I can remember 
situations where the information would have been useful.

View raw message