We need to identify the appropriate point in a query's lifetime to record:

• The query body as received by mongos
• The query start time
• The query end time
• Data from the query response (not yet determined)
• Additional metrics (not yet determined)

The query body is available in (among other places) RequestExecutionContext::_request or [CurOp::_originatingCommand|] and the lifetime of the OperationContext is tracked by a Timer. CurOp also tracks _start, which may also be sufficient.

Ideally this would be after the query response has been handed off to be written over the network, to avoid delaying user queries. However, if required for ease of implementation it may be earlier than this.

Only mongos needs to record queries, but changes can affect mongod code, as later changes will only enable recording on mongos.

The exact data to be gathered from query responses is not yet defined - it is likely to include information like cursor, for future tickets to address correctly performing getMore on a cursor returned by an earlier query. The recorded getMore request will include "stale" cursor info from the customer cluster.

Further, later investigation may find that additional metrics should be recorded to support comparison of the original and replayed workload.

As the response data and additional metrics are both undefined as yet, they should be considered (e.g., access to the OpCtx may be required if metrics are later stashed there) but don't need to be gathered yet. As they are likely to vary by query type, if required an empty BSONObj may be a suitable placeholder.

—

The result of this ticket will be a stub method (to be populated later to pass along data to be recorded) which is called at the end of each query with the above information.

Later work may extend this method with additional metrics to record.