It would be useful to have a "Test Alert" button for each configured alert in order to integrate and test alerts with third-party systems. Otherwise, it is difficult if not impossible to determine what the alert will look like until it is triggered.

Add third-party service integration for Microsoft Teams, as we do for Slack.
Most likely the following can be leveraged to achieve the integration: https://docs.microsoft.com/en-us/graph/teams-proactive-messaging

Ops Manager Application needs a way to backup and restore AppDB without Ops Manager Downtime to recover from infrastructure failures or fatal errors.

Streaming snapshots during a restore from a blockstore out to the MongoDB Agent cases the RTO (recovery time objective) to grow linearly with the compressed datasize in the largest shard/RS of the snapshot. The RTO of an Ops Manager restore could be very significantly improved by leveraging volume management infrastructure (such as from VMWare) to restore previously acquired snapshots as virtual filesystems (volumes).

In order to test snapshots automatically, create a new job type that allows the Backup Daemon to download the snapshot from the snapshot store, then run validate on each collection.

If any collection fails validation, send an alert to the Backup Admin with the list of corrupted data.

We should expand the Ops Manager API to provide mms0.log downloads the same way we allow mongod deployment log downloads. This will help users with diagnostics when they deploy many Ops Manager instances via the kubernetes operator but do not yet have centralized logging.

MongoDB Operator can only deploy and manage MongoDB in a single Kubernetes cluster. However, for DR and global apps, it is important to deploy a single DataBase across multiple Kubernetes clusters to allow for DR or globally distributed apps.

Integration with Rocket.Chat like done in Slack.

Currently, Ops Manager user may require to add the CA for the TLS enabled destination such as SMTP Server, on-prem S3, Webhook Endpoint, etc directly to the Java Trust Store. Adding CA to Java Trust Store also requires to re-apply if Ops Manager Application is upgraded or re-install.

It would be best to have a feature in Ops Manager so that the user is able to upload the required CA via UI.

Migrating large sharded clusters to a different cluster pre-sharded with different shard keys requires a significant amount of time to balance post-restore.

This is a feature request to restore a snapshot on a per document basis through a mongos. The desired result is a completed restore with collections/documents residing on their target shards.

Up until Ops Manager version 4.0+, we are/were able to view "Properties" of all servers/Replica sets by clicking on the ellipsis option on the each server. But will the latest versions of Ops Manager, that option is no longer available. We are often looking to quickly identify the allocated resources such as CPU/RAM on servers to help troubleshoot and deduct if we need to add more resources, so this has been a helpful feature we have used. We would very much like to see this feature option to be revived in the current versions of Ops Manager 4.2 and 4.4.4.

Our standard replica set deployments require a number of items to be set in the edit/modify area of each replica set...such as:
sslMode
directoryPerDB
directoryForIndexes
javascriptEnabled
redactClientLogData

Since we create hundreds of replica sets the amount of time spent repeatedly setting these attributes, which are considered "default" in our shop, adds up. Having the ability to set a template of defaults per project would save a great deal of time.

Currently, the Ops Manager UI under Continues Backup only shows the following information about the snapshots:
- Replica set name
- Status
- Last Snapshot
- Last Oplog Slice

It would be very helpful to also see:
- Start date/time
- Finish date/time
- Backup duration
- Snapshot size

In some particular situation indexes need to be rebuild.
It would be nice to support a rolling index rebuild like Ops Manager does for the standard create index.

If you want to catch full scan on collection you could set up alert "Query Targeting: Scanned / Returned > 1".
OPS Manager does not provide any details where it was triggered.
it would be nice to get db/collection/query which caused this issue. Query still can be fast (for example, not many document in collection yet or hardware is idle/fast at the moment) and will not go to slow operation group.

Currently our Ops Mgrs keep re-downloading EOL releases of mongodb, e.g. mongodb-linux-x8664-2.6.12, mongodb-linux-x8664-3.0.15, etc. Ops Manager should automatically exclude EOL releases - they are taking up unnecessary disk space.