Allow the possibility of performing a snapshot on-demand.

Usually the snapshot time ends too far away in time after configuration changes of the backup job (i.e: changing the block size). For testing purposes it would make sense to allow performing a snapshot on-demand to get it generated and proceed with further testing/tuning if required.

Why doesn't MongoDB provide a tool (integrated or standalone) to operate document migration across on-prem (sharded) clusters? Suggestion might be to officially support tools like "mongo push", which may cover situations of hardware changes, production servers migration, re-sharding.

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.

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.

Problem Statement,
What is the problem? MongoDB Agent (Automation Module) attempts to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509.

Why is this a problem? MongoDB Server process logs are flooded by unnecessary noise from such MongoDB Agent (Automation Module) failed auth attempts.

Example,
{"t":{"$date":"2021-05-10T11:08:02.115+0000"},"s":"I", "c":"ACCESS", "id":20249, "ctx":"conn115","msg":"Authentication failed","attr":{"mechanism":"SCRAM-SHA-1","principalName":"__system","authenticationDatabase":"local","client":"10.10.10.10:46765","result":"AuthenticationFailed: ###"}}

Proposal,
* Don't attempt to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509 in MongoDB Server

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.

Weekly alerts report as part of the UI with the option to download export to pdf

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

Atlas -> please make buffers, cached, and MEM shared available under system memory metrics on Atlas for end users so we can calculate the criteria for auto scaling .

Currently only Mongodb support can see these three metrics

In Ops Manager, it is not possible to obtain some data from each snapshot via api, it is only available in ops manager interface. It is a good a idea to obtain from each snapshot the information of the backup resource usage. The api could return this information: "Store Type, Store Id Live, Compressed Bytes Dead, Compressed Bytes Compression Ratio, Last Groom, Last Track"

If you are using local key file encryption and backing up your MongoDB deployment using Ops Manager, backups won't work correctly if you upgrade to MongoDB 4.2. The correct solution is to switch your encryption to KMIP. But if you try doing that, automation will get stuck!

mongocli output text format not displaying all information where as json format dispalying all, if text can display same information as in Json. Will be helpful in updating the alerts etc.

export & import alerts settings from one project to another project

Labels and annotations added to Kubernetes resources by the MongoDB Enterprise Operator should include a prefix designating that it was added by MongoDB. The lack of a prefix suggests the field and values are private to the user.

For example, the MongoDB statefulset and service selector should use a label prefixed with a MongoDB domain.

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set

It would make things easier for our users if they had at least a starter/example AWS CloudFormation template to use for provisioning AWS resources required for an Ops Manager deployment.

spec:
members: 1
type: ReplicaSet
version: "4.4.5"
statefulSet:
spec:
template:
spec:
volumes:
- name: data-volume
emptyDir: {}
- name: log-volume
emptyDir: {}

This type of override would be very helpful for automated testing pipelines - pipeline should spin up single mongodb instance, populates data and proceed with application testing. For that, we don't need persistent volumes, we need clear folder on each invocation.

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)