Problem:
With the switch to Structured Logging and the inclusion of OCSP options within the driver and server, when OCSP errors occur, the associate log lines do not include a connection ID, therefore cannot be definitively tracked back to the client/source of the error.

Example:

{"t":{"$date":"2021-09-03T14:24:44.242+00:00"},"s":"W",  "c":"NETWORK",  "id":5512201, "ctx":"OCSP Fetch and Staple","msg":"Server was unable to staple OCSP Response","attr":{"reason":{"code":141,"codeName":"SSLHandshakeFailed","errmsg":"SSL peer certificate revocation status checking failed: Could not verify X509 certificate store for OCSP Stapling. error:00000000:lib(0):func(0):reason(0)"}}}

This makes filtering internal Atlas issues difficult to separate from client-side issues, and has lead to multiple support tickets where customer quote these log lines as reasons for application connection problems.

Proposed Solution:
Include the connection ID in the log line so that we can provide a "complete connection lifetime" from the server logs, and filter actual issues from Atlas noise.