As tracked on SERVER-19318, the query team is currently re-implementing the currentOp command by way of a new aggregation stage, $currentOp. Part of the motivation for this is to allow users to more easily filter and analyse currentOp data by passing it through an aggregation pipeline. However, in the case of a sharded cluster, the existing currentOp output has some shortcomings.

In particular, we do not include the name of the shard/host from which each operation originated. We do prepend the opID of active operations with the shard name, as shown below:

{
	"desc" : "conn",
	"threadId" : "0x7000061c5000",
	"connectionId" : 9,
	"client_s" : "192.168.1.10:56870",
	"appName" : "MongoDB Shell",
	"clientMetadata" : {
		...
	},
	"active" : true,
	"opid" : "shard03:7978",
	"secs_running" : 0,
	"microsecs_running" : NumberLong(66),
	"op" : "command",
	"ns" : "admin.$cmd",
	"command" : {
		"currentOp" : 1,
		"$all" : true,
		...
	},
	"numYields" : 0,
	"locks" : {

	},
	"waitingForLock" : false,
	"lockStats" : {

	}
}

However, inactive connections do not have an opID, and therefore contain no information identifying what shard/host they came from:

{
	"desc" : "ftdc",
	"threadId" : "0x700010583000",
	"active" : false
}

This means that something as simple as grouping by shard is cumbersome for active operations:

pipeline: [
	{$currentOp: {}},
	{$group: {_id: {$arrayElemAt: [{$split: ["$opid", ":"]}, 0]}}}
]

... and impossible for inactive connections.

To better support aggregating the $currentOp output in a sharded cluster, each currentOp document should include the shard and host names when running in a sharded context.