Enhance logs to support troubleshooting errors

[sciurus]

Right now, when the top sites proxy returns an error code like 500 it is difficult to determine if it is because

a) the partner returned this error and we are proxying the response b) the proxy itself experienced an error

I think a good way to address this is to add some more fields to the logs. Here are two that I would find useful specifically for requests under /cid/

• upstream_response_time: how long it took to receive the response from the partner
• upstream_status: the response code we received from the partner.

and here are three I'd find useful for all requests.

• request_time: how log it took in between when the first byte was read from the client and the last byte was written to the client
• status: the response code we're sending to the client
• trace: the value of the x-cloud-trace-context header. this lets us tie this application log together with the nginx and load balancer log lines.

For timings, seconds with millisecond accuracy (e.g. 0.123) would be good. If for some reason we didn't receive or send a response code, we could log 0.

[sciurus]

@jbuck anything else come to your mind that the proxy should log?

[jbuck]

hmmm, are there any other upstream headers that we'd be interested in logging? other than that, latency and response code is good

[sciurus]

I can't think of any headers we'd want that aren't in the nginx logs, and once we have x-cloud-trace logged by the app we can tie the two together.