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

The ability to Test Failover was added to Atlas https://docs.atlas.mongodb.com/tutorial/test-failover.

Please add this functionality to Ops Manager in order to facilitate failover testing. This is especially useful in multi-tenant Ops Manager setups.

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.

What is the problem that needs to be solved? SNMP traps for AUTOMATION_AGENT_DOWN, MONITORING_AGENT_DOWN, BACKUP_AGENT_DOWN alert types does not contain hostname information in .1.3.6.1.4.1.41138.1.1.1.4 (.iso.org.dod.internet.private.enterprises.mms.server.serverMIBObjects.mmsAlertObject.mmsAlertHostAndPort) OID.

Why is it a problem? (the pain) User is blocked to act quickly on the alert and identify the host where Ops Manager's Automation/Monitoring/Backup Agent is in DOWN state. Missing <HOSTNAME>:<PORT> information at .1.3.6.1.4.1.41138.1.1.1.4 SNMP OID does not allow user to map AUTOMATION_AGENT_DOWN, MONITORING_AGENT_DOWN, BACKUP_AGENT_DOWN alert types into a particular hostname.

Apply Project Maintenance Windows to Global Alerts

Make the existing Project-level maintenance windows also silence Global alerts associated with the Project.

We have many projects that share the Global Alerts and do not want to turn off all global alerts as we still need that alerting for the projects that are not being worked on.

In combination with the existing API for Project Maintenance Windows, this really allows full control.

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.

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.

In order to better troubleshoot snapshot performance issues, or maintain an understanding of how snapshots are performing and whether one is approaching a threshold where they wont be able to keep up, its a good idea to expose how long a snapshot took in the View All Snapshots page. This would also aid in quickly identifying which snapshots are full vs incremental.

This feature request is for a new Group/Project API call for the management of the host mappings created in Ops Manager from monitoring information. Whether it be an endpoint for "Reset Duplicates" or full featured create/delete of individual host mappings, both will alleviate issues where overlapping mappings affect monitoring in Ops Manager.

Note: The issue of overlapping mappings may occur when a mongod process has moved/changed IP addresses multiple times. With enough cycling (as seen in Kubernetes clusters with frequent pod restarts), eventually a previously mapped IP address may now be associated with a different mongod process.

Get Database Measurements currently provides information from dbStats.

Adding collection level statistics would be useful for gathering information via the API on a regular basis to measure growth of each collection and other metrics. Data Explorer functionality is not available via the API.

When restoring a snapshot through Ops Manager, automation will create the config file for you. But if you're restoring a snapshot manually, there's no config file! Surely we can include a sample mongod.conf withe sufficient information filled out to help a user get up and running again.

Today, it is possible to install MongoDB software (mongoimport/export, mongodump/restore, mongo, bi connector) from Ops Manager via the automation agent.

Ideally, it will be possible to have the same experience for the new MongoDB Shell (mongosh), so that customers don't need to put in place a separate set of processes nd scripts to install it.

Currently, there is no way to enable LDAP Auth for the Ops Manager Users via an API call.

This essentially means that one would not be able to use LDAP and ci/cd simultaneously with Ops Manager.

Mongodb enterprise support has confirmed that in the event of disaster recovery or a deployment of a new cluster, manual steps must be done to enable LDAP during a ci/cd deployment.

It should not be expected to sign in and manually do anything in a web gui in an enterprise solution. It is simply not scalable.

MongoDB Ops Manager would need to expose endpoints for Prometheus for MongoDB Clusters. There are a number of metrics that popular MongoDB Exporters do not provide, for example:
1. Enterprise Backup status
2. Replication Alarms
3. Agent statuses
4. A number of Cluster statuses
etc

There is no way to get this data into Prometheus at the moment

The LDAP Query user's password appears in plain text in mongod.config file. The ability to mask its password in automation config file using credentialstool would mitigate a security risk.