https://review.openstack.org/#/c/21334 introduces a significant change to the way logging works in swift.
Currently, each module in the pipeline has its own logging configuration under its section heading. This change means that most of that can be done away with, instead adding additional instances of proxy-logging in the pipeline.
39 The proxy-logging can be used twice in the proxy server's pipeline when there
40 is middleware installed that can return custom responses that don't follow the
41 standard pipeline to the proxy server.
42
43 For example, with staticweb, the middleware might intercept a request to
44 /v1/AUTH_acc/cont/, make a subrequest to the proxy to retrieve
45 /v1/AUTH_acc/cont/index.html and, in effect, respond to the client's original
46 request using the 2nd request's body. In this instance the subrequest will be
47 logged by the rightmost middleware (with a swift.source set) and the outgoing
48 request (with body overridden) will be logged by leftmost middleware.
49
50 Requests that follow the normal pipeline (use the same wsgi environment
51 throughout) will not be double logged because an environment variable
52 (swift.proxy_access_log_made) is checked/set when a log is made.
53
54 All middleware making subrequests should take care to set swift.source when
55 needed. With the doubled proxy logs, any consumer/processor of swift's proxy
56 logs should look at the swift.source field, the rightmost log value, to decide
57 if this is a middleware subrequest or not. A log processor calculating
58 bandwidth usage will want to only sum up logs with no swift.source.
too old to worry about now