Hi Graham, tanks for the detailed explanation. I understand the difficulties to make the unique log ID transferred to the deamon process since as you have said it is only generated on the first request by Apache.
You also mention that in your setup the client IP is successfully transferred to the deamon. I could see this working as an rough solution to correlate the log entries, i.e., using client IP+ timestamp and maybe proc ID. Unfortunately, I cannot get this to work, since for any message logged to stdout/stderr the client IP also gets lost (not shown in Apache error log). Are you using environ['wsgi.errors'] for this or should it work out-of-the-box with standard Django stderr logger? Thanks, Stefan On Friday, August 5, 2016 at 2:18:35 PM UTC+2, Graham Dumpleton wrote: > > > On 5 Aug 2016, at 9:54 PM, Stefan Nastic <[email protected] > <javascript:>> wrote: > > Is there a way to configure the logging with mod_wsgi and Django without > losing the request information, such as remote client IP or unique log ID > AND without using environ['wsgi.errors']? Other solutions such as logging > wrapper would be also acceptable... > > Please also see related SO discussions: > > http://stackoverflow.com/questions/38786532/logging-with-apache-2-4-mod-wsgi-and-django > > http://stackoverflow.com/questions/38767989/apache-2-4-error-log-entries-incomplete > > > Short answer, no. > > The two basic problems are detailed in: > > https://github.com/GrahamDumpleton/mod_wsgi/issues/144 > https://github.com/GrahamDumpleton/mod_wsgi/issues/145 > > but the solution even for the first is far from simple. > > The problem is that the request and connection log IDs are only generated > the first time a message is logged via the Apache log API. In the case of > proxying a request from the Apache child worker process to a daemon mode > process, there wouldn’t have been any messages logged and so nothing has > triggered the generation of the log IDs. This means they aren’t available > to transfer across to the daemon process such that they could be > reconstructed into the connection and request records to fake up things so > that logging works in daemon mode. A solution may be for mod_wsgi to > forcibly cause the generation of the log IDs on every request using an > Apache API call, even though they may not be required. The implications of > doing this need to be looked at. Alternatively, one works out what seed > information from a request is used to generate the log ID so can ensure > that is being passed across and added to the fake connection and request > objects that the logging will eventually use. > > You also keep saying remote client IP doesn’t show. On my testing on MacOS > X it does and the client IP is transferred across to daemon mode, so not > sure what the issue is there as cannot replicate it at this point. > > So trying to address even the log ID issues for wsgi.errors is going to > take some time and work. Linking messages to stdout/stderr back to requests > is going to be even more complicated. > > Graham > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
