Currently, an aggregate operation which reads the plan cache as a "virtual collection" using $planCacheStats is not supported when connected to mongos:

mongos> db.testColl.aggregate([{$planCacheStats: {}}])
2019-11-25T10:55:59.025-0500 E  QUERY    [js] uncaught exception: Error: command failed: {
	"ok" : 0,
	"errmsg" : "$planCacheStats cannot be executed against a MongoS.",
	"code" : 50932,
	"codeName" : "Location50932",
	"operationTime" : Timestamp(1574697353, 1),
	"$clusterTime" : {
		"clusterTime" : Timestamp(1574697353, 1),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
} : aggregate failed :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:612:17
assert.commandWorked@src/mongo/shell/assert.js:702:16
DB.prototype._runAggregate@src/mongo/shell/db.js:266:5
DBCollection.prototype.aggregate@src/mongo/shell/collection.js:1012:12
@(shell):1:1

Instead, users are expected to connect directly to the mongod of interest in order to examine that node's plan cache.

In some environments (e.g. Atlas), it may be difficult or discouraged to connect directly to a shardsvr. Furthermore, some users may wish to examine the plan caches on all nodes before drilling down into particular nodes of interest. Therefore, we should add support for $planCacheStats issued via a mongos. The most sensible behavior for such an operation would be to return the union of the plan cache entries from every shardsvr node in the cluster (as opposed to obeying the read preference and returning the plan caches for a particular node in each shard). This may require some work in the sharding infrastructure to allow an aggregate operation to target every node. The current infrastructure typically assumes that at most one host in each shard is targeted.

Finally, in order to allow users to filter, sort, group, etc. based on the host, we should augment each plan cache entry document in the result set with host:port information in the case of a sharded $planCacheStats.