On 09.06.2010 14:37, Jeff Trawick wrote:
On Tue, Jun 1, 2010 at 8:56 AM, Rainer Jung <[email protected] <mailto:[email protected]>> wrote:I repeatedly inserted millisecond or microsecond timestamps as well as PID and thread ID information into the ErrorLog when trying to diagnose problems, most often in combination with additional log lines. Due to the increased load and capability of systems and increasing amount of concurrency, would those features be interesting by default? I realize it is a bit late for this... 1) Sub-second timestamps in error log 2) PID and thread ID 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. Apologies if I misunderstand what is already committed... (swamped) Any thoughts about making this extra information configurable?
See the latest replies in this thread. Stefan compiled a list of things that could be interesting to log (and would be to huge to add by default) and I was asking whether copyin something from mod_log_config would be helpful (forma patterns and callback functions).
(Would you want your prefork error log to have a different format than your worker error log, for example? (thread id)
The tid has already been removed if the MPM is not threaded. There is discussion though, how to best cache this information (threaded or not), because the dynamically loaded MPM can now change between reloads (yes it works) and a simple static variable in the parent won't be reinitialized during reload.
Would you even want you httpd 2.4 error log to have a different format from your 1.3-2.2 error log, at least until you can update any parsing scripts?
In my opinion that should be allowed in a 2.2 to 2.4 change. The changes to the format are pretty trivial to add to parsers (ignoring additional tokens).
Any thoughts about modules being able to control some or all of this extra information?
Not yet, but if we clone the mod_log_config solution they could register callbacks.
A real world example would be a system (perhaps a set of products with common logging standards) with its own request correlation (some unique id) which is already implemented by many components. It is important for the Apache logs to use that particular id.
Right. But if you are in front of the id generating system (as the web server often is) you are out of luck and then you would be the generating system yourself. If your are somewhere behind, you could extract from headers and then use your other suggestion (let modules influence the common part of the error log line).
Regards, Rainer
