Add the ability to schedule groom jobs at a specific point in time. Also expose this functionality through the API for easy modifications through configuration management tools.

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.

Enhance the Ops Manager feature for the detecting of broken processes, validating its sanity, so that Ops Manager could "un-break" processes and start regular backups without any manual intervention.

Clicking on the "Connect to this replica set" should open a modal that includes the Replica Set horizon host and port (if configured) in addition to the host's FQDN. This will help users determine their connection settings without requesting details from the kubernetes cluster administrators that deployed the database.

Currently, MongoDB doesn't provide any way to enforce password policies. If there is some way for Ops Manager to enforce a configurable password complexity and age for user accounts managed through Ops Manager, that would be huge win. This can be as simple as adding UI-level validations to the create/edit user form.

Naming or tagging Ops Manager daily/weekly/monthly/yearly backup snapshots

Currently it is required to enable automation on a cluster in order to monitor system level statistics such as CPU.

As automation is sometimes not desired for a cluster, please add the ability to gather system level metrics when a cluster is monitored only.

Hello,

On a sharded instance, I try to identify the connected physical people.
It is not easy. I cannot identify my own connection. 😦

Can we have a command to find out who is connected to the platform (excluding host2host connections, backup process, ...)?

The closest command but not complete and friendly :
use config
DBQuery.shellBatchSize = 300
db.system.sessions.aggregate( [ { $listSessions: { allUsers: true } },
{ $project: { _id: 0, "user":"$user.name" } } ,
{ $group : { _id: {"user": "$user" }, count: { $sum: 1 } } },

])

Regards
Jerome

Can we have add dashboard feature in ops mgr which can give consolidated metrics of all RS.

Sometimes it would be great if we could move the conf, tmp, or logs directories to other filesystems and use symlinks so that Ops Manager doesn't have to worry about where the needed file physically are. Right now, Ops Manager refuses to start whenever this sort of redirection is done.

1. Slow queries report similiar to AWR report in Oracle
2. List of hosts being monitoring in Organization and project level in a downloadable format
3. Metrics report for all the hosts at org and project level
4. Backup failures report
5. Alerts report (Example : List of alerts triggered in given timeframe)

Ops Manager should allow Data Explorer to be configured with a Read Preferences and maxTimeMS options. Not having these options allows this tool to potentially trigger un-optimized queries to only hit primary nodes, which for high load production environments may cause un-expected problems.

Add a filter for Global alert Configuration Page. It would be nice to have the ability to search for the specific alert to see if you have it configured and for which environments.

A filter similar to what is seen on the "Open Alert" view would be sufficient.

Since we are managing upwards of 50 deployments via Global Alerts this would be a useful feature.

Version 4.4 has support to monitor the App DB. Please add the ability to monitor the backup database as well.

The login page for Ops Manager 4.4+ shows "Email Address" and "Password". While using other login methods such as LDAP, an email address may not be used.

It would be more accurate to say username here.

For users running DBaaS MongoDB products powered by Ops Manager automation, it would be useful if the API provided a way to replicate the cluster import behavior where MongoDB users are automatically discovered. This would help in scenarios where an existing Ops Manager deployment fails, and hundreds of deployments need to be moved to a different Ops Manager without knowing what MongoDB credentials the end user of that deployment had created. Having this API would allow the DBaaS provider's own scripting/automation to orchestrate moving these deployments to a new Ops Manager stack with reduced downtime.