When using the Logger provided on the RequestContext, some properties are already included by default; most usefully for correlation of multiple log entries is the request ID. Unfortunately the only place in the logs that the source IP and port of the connection through which the request was sent appears not to contain this request ID:
Aug 15 04:03:11.580 INFO accepted connection, remote_addr: 10.1.1.90:47312
Aug 15 04:03:11.580 WARN lunar waneshaft not ambifacient, uri: /prefabulate/amulite, method: POST, req_id: acd330b9-9e9c-494d-ac7a-610ba0fc8933
Aug 15 04:03:11.581 INFO request completed, error_message_external: invalid, error_message_internal: invalid, response_code: 400, uri: /prefabulate/amulite, method: POST, req_id: acd330b9-9e9c-494d-ac7a-610ba0fc8933
One imagines the request ID is not actually available yet at the time we receive the incoming connection, as it will presumably be taken from a request header (if provided) to allow tracing. It seems like we could, then, do at least one of:
- another ID that tracks the connection; e.g.,
$PID/$CONNID where CONNID would start at 0 and increment for each connection served by this process. This could also be a UUID separate from the one the client passes in, which may subsequently be useful for OpenTracing-style spans and sub-spans anyway.
- the remote_addr field appear in each log line as well as the request ID
- defer emitting the
accepted connection message until we have enough context to know what the request ID is (seems not great)
When using the
Loggerprovided on theRequestContext, some properties are already included by default; most usefully for correlation of multiple log entries is the request ID. Unfortunately the only place in the logs that the source IP and port of the connection through which the request was sent appears not to contain this request ID:One imagines the request ID is not actually available yet at the time we receive the incoming connection, as it will presumably be taken from a request header (if provided) to allow tracing. It seems like we could, then, do at least one of:
$PID/$CONNIDwhereCONNIDwould start at 0 and increment for each connection served by this process. This could also be a UUID separate from the one the client passes in, which may subsequently be useful for OpenTracing-style spans and sub-spans anyway.accepted connectionmessage until we have enough context to know what the request ID is (seems not great)