When application issues are reported, typically the only artifact that can be shared is a log excerpt with stack traces. Applications are not instrumented by default in a way that engineers can easily diagnose client-side issues, and requesting this instrumentation be added to a workload can further delay an investigation (and frustrate users who have to do this work). Even after instrumentation, the factors contributing to the initial event may be difficult to reproduce and observe.

The MongoDB Server implemented a Full Time Diagnostic Data Capture mechanism in 3.2 that Technical Services engineers have used to troubleshoot performance and behavioral issues more rapidly and efficiently, however there isn't a standardized method for diagnosing client-side issues within the Drivers ecosystem.

When developers are looking to diagnose client-side issues, the information that is typically required from on or more MongoClient instances is (a) topology details, (b) client/host latency details, (c) operation counters and other information used for server selection.

Unlike DRIVERS-2455 that was effectively trying to reproduce FTDC on the client side, what we actually need to improve our observability posture is a mechanism to enrich the hello commands used by drivers for heartbeats to transmit additional information about the current state of the MongoClient (as performance counters), which can be captured by the server and recorded as FTDC. This would ensure that during a postmortem analysis, host process behavior can be compared with the client-side view of the connection profile and topology view.