What is the problem that needs to be solved? Ability to turn on/off MongoDB Agent auto-update in specific/all Cloud Manager/Atlas Project(s).

Why is it a problem? (the pain) Cloud Manager/Atlas Project will warn a user with One or more software components are out of date: MongoDB Agent every time a new version of MongoDB Agent is released, so a user will need to always manually click on Update Software Components button to get rid of that warning (filename: 2020-04-06mongodbagentupdatewarning.png). Frequent updates of MongoDB Agent creates lots of noise for users who is willing to get rid of out of date: MongoDB Agent warning in their Cloud Manager/Atlas Projects.

What is the problem that needs to be solved? We already collect serverStatus.uptime counter info from each and every MongoDB Server process, so we just need to add serverStatus.uptime counter info into Metrics so that it will be possible to track serverStatus.uptime changes through the time.

Why is it a problem? (the pain) If you'd like to calculate MongoDB Server process availability to know for how long your MongoDB Server process(es) was/were up and running, you'll need to analyze MongoDB Server process logs (in case if they are ever available for required period of time) to see last time MongoDB Server process was stopped/started. With serverStatus.uptime counter info available in Metrics at Ops Manager side it will be very easy (also programmatically via Public API call) to identify down time of MongoDB Server process since serverStatus.uptime counter will be reset every time MongoDB Server process is restarted (i.e. a MongoDB Server process restart will always be indicated easily).

It would be helpful if, on the Snapshot overview page or on the Admin -> Backup page, there was the ability to benchmark the backup to help identify bottlenecks.

Allow the user to select a deployment to test and then do a random sampling of data (ie: 100MB) to a temporary Snapshot location and then graph out the metrics for things like Memory/CPU/Disk IO on the source host, Database performance, Backup Agent performance, Network throughput, Blockstore/File System Store/S3 write performance, etc.

Then create a report based on this benchmark that can be sent to technical support for recommendations.

This will help the user identify potential bottlenecks before they become a serious issue and assist technical support in helping the customer have a positive experience.

When restoring a sharded cluster snapshot, provide a means of mapping the source shard replica set names to the target shard replica set names. This will allow users to predictably restore large/small shards to the appropriate target hosts.

Currently, this can be done for sharded clusters with fewer than 10 shards by naming the shards in a predicable shard## pattern. However, greater than ~10 shards leads to an alphabetical => alphanumeric restore plan (e.g. shardA10 restores to shardB2).

Restoring large sharded clusters can also overwhelm networks where MongoDB Agents are downloading snapshots from Ops Manager(s) at the same time. Please consider providing a mechanism to throttle the number of Agents concurrently downloading snapshots with the understanding that this will come at a cost of longer restore times. This is helpful for large restores scheduled on a regular basis with expected downtime of a QA or UAT environment where uptime is not a priority.

What is the problem that needs to be solved? Add hostname/port attributes into all Cluster/Replica Set alert types generated via SNMP Alert Traps, Ops Manager's Public API calls (Project/Global Alerts) and Alert Webhooks (Project/Global Alerts).

Why is it a problem? (the pain) Hostname/port attributes are currently missed in Cluster/Replica Set alert types and we only provide a name of the Cluster/Replica Set for which the alert was generated. Operator who watch Monitoring System (the one that receive Ops Manager Alerts) needs to see hostname/port information of a Shard/Replica Set for which such alert was generated, in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive the alert from Ops Manager) needs to do additional work for alert received (via additional API calls (if possible at all)) in order to get hostname/port for each process of Cluster/Replica Set.