The Top class keeps an operation latency histogram for each collection. However, this is currently only plugged into mongod. This means that we don't currently track operation latency on mongos.

This ticket is to evaluate the best way to get this functionality onto the mongos. There are two requirements we need to fulfill:

1. Figuring out the best place to record the end of an operation (a mongod example here. You can also grep for all other places where Top::record is called).
   1. Read and write operation logging could be placed here. This mirrors the location of read operations monitored on the mongod.
   2. Command-based operation logging is a little tricker, since writes can come in as commands as well. If we have a write come in as a command, its ReadWriteType as seen by CurOp will be a command. Whoever does this ticket will need to be careful in separating out actual writes from other command operations, and in making sure that operations aren't double-counted. In a local patch, I special-cased inserts and updates in the cluster write command operation counting logic here, but this is by no means an official endorsement for where the operation should be recorded.
2. Figuring out the best way to expose this information to a client. In a local patch I added in the latency stats to the cluster coll stats command here. Current convention has us leaning towards using the collStats aggregation stage instead, so the ticket assignee may want to consult with Query to figure out the best place to expose this information.

We will also need to look at the rest of the functionality of Top.h, and see if it's something we want to fulfill. There are more metrics than we currently intend to use, and some information may not make sense on a mongos (tracking the Read/Write lock type used for an operation). So attention should be paid to separating out the logic we need – maybe separate files for tracking on mongos/mongod?