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).

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

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.

When checking the backup job details for a 4.2 deployment, this is always reporting to be performing a "WT Checkpoint" even though it is not exactly generating a snapshot at that point in time.

The request is to enhance the reporting for this summary table in order to get further details on what the Backup Module is doing at that precise point in time. If it is awaiting for the instruction to execute a snapshot, in the process of transferring blocks, etc.

All of our hosts are in the same TZ. We would like to be able to set the Ops Manager related logs timestamps to our local TZ.

In order to separate replication, client and administrative traffic, servers may have multiple network interfaces using different IP and hostname aliases associated with them.

According to the requirements described on https://docs.opsmanager.mongodb.com/current/tutorial/provisioning-prep/#server-networking-access Automation currently can use only the server hostname defined as hostname -f and cannot use any of the other aliases matching to other IP addresses for the other machine host aliases.

Please add some way to customize which host alias Automation should use as a configuration parameter for the Agent.

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.

On Servers Page, Activate/Deactivate Monitoring/Backup module should be activated. So that multiple monitoring module should be activated for hot stand by.

Currently Ops Manager CRD deployment requires configuration using GUI which is a manual step. An option completely define all OPS Manager settings / Org in declarative manner via yaml will be great in building completely automated CI/CD Pipelines

What is the problem that needs to be solved? MongoDB Agent service (mongodb-mms-automation-agent.service) does not start (by default (disabled; vendor preset: disabled)) automatically after OS reboot.

Why is it a problem? (the pain) OS restarts can be frequent, and current default behavior (disabled; vendor preset: disabled) of MongoDB Agent not to start after OS restart causing additional downtime for customers.

My automation manager posts an info message about unexpected fields in process memory metrics map every minute. It's polluting my logs. I would like a way to fix the underlying problem or, if it cannot be fixed, then don't tell me about it in the logs.

Here are some examples:
mongodb-data-prod-vm2.cloud.ca 2020-08-05 - 01:10:47 PM info runtimestatsPrinter Unexpected field in process memory metrics map: thp_enabled. Skipping

mongodb-data-prod-vm2.cloud.ca 2020-08-05 - 01:10:47 PM info runtimestatsPrinter Unexpected field in process memory metrics map: speculationstorebypass. Skipping

> 1.) What is the limiting factor of the Operator? Is it number of Pods, number of Custom Resources (e.g. MongoDB, MongoDBUser) or something else?

> 2.) What does the number of "Clusters" refer to? Does it differ for Standalone, ReplicaSet and ShardedCluster?

> 3.) How many instances of the "Clusters" in 2.) are supported per MongoDB Operator?

Is there any way to add this sort of data to our documentation?

Thanks

What is the problem that needs to be solved? Customers run into SSL/TLS Certificate Expiration issues (where SSL/TLS certificate has expired) on their Ops Manager and MongoDB Server environments and they do not get any early notifications from Ops Manager about SSL/TLS Certificate Expiration.

Why is it a problem? (the pain) Customers who use Ops Manager to manage/monitor their MongoDB Server deployments are running into situation where their configured SSL/TLS Certificates are expired, and thus have potential downtime for their applications.

please provide an option in Ops Manager to monitor the balancer status and add to alerts?
So, we will know if balancer is not running.

Note:
Normally the balancer would be disabled during backups and during a scheduled Balancing Window downtime.
I believe that the Balancer has a duty cycle of either 10 secs when nothing recently to balance, or 1 sec when there's a bunch of balancing to do.
Any alert would need to account for these:
the changelog shows chunk moves commanded
the actionlog shows balancer state change history
the settings collection has the balancer state