The getMore command in the upcoming 3.2 release currently has a format of:

{
  "getMore": <int64>,
  "collection": <string>,
  "batchSize": <int64>,
  "maxTimeMS": <int32>
}

This is inconsistent with other commands that expect a collection name as one of their elements in the document - the expectation is that the command follows a format of (such as find, killCursors, update, delete, etc):

{ commandName: <string>, ... } 

I am proposing for consistency we change the getMore command to:

{
  "getMore": <string>,
  "cursor": <int64>,
  "batchSize": <int64>,
  "maxTimeMS": <int32>
}

Why does this matter?

The the introduction of command monitoring specification in the drivers and implementations already live in the wild from New Relic, etc expect that commands that execute on a collection follow a format of { commandName: collectionName } in order to generically parse the collection name from the events. Not following this format forces 3rd party subscribers to make exceptions based on the command name, which is against the principle of command monitoring to begin with – we wanted to provide them with an API to subscribe to without having driver or server changes force them to modify their APM subscribers.

Sorry for the late ticket, but I just noticed this now when working on a demo for New Relic for their FutureStack conference... A sample screen shot of what it looks like in New Relic based on their assumptions and our specification is attached - getMore is grouped by cursor id which causes them to not be able to group the events properly by collection without an exception for this case.

A link to the drivers' command monitoring specification:

https://github.com/mongodb/specifications/blob/master/source/command-monitoring/command-monitoring.rst