On Tuesday 01 June 2010, Rainer Jung 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?
Absolutely. Either by default of by some config directive. Having to recompile modules to get such information is a PITA. > 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 "-". 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, ... But I think a shorter id than the 20+ bytes of the unique id would be sufficient in most cases, and cause less disk space usage. I guess it would be good enough if the id is unique for one httpd instance in one day. Of course, if mod_unique_id is loaded, its long unique id could be used. Cheers, Stefan
