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.

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

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

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.

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.

Ops Manager currently allows the ability to rotate audit logs based on the threshold settings in the Update MongoDB Log Settings modal but audit.logs do not compress/delete as the mongodb.logs do from the same modal. We would like the ability to either toggle compression/deletion of audit.log in that modal or a separate modal. We think a separate modal would be better since audit.logs may be used for security forensics and require a longer retention period.

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

Support arbiters with MongoDB Kubernetes Operator so that Replicasets should be deployed in PSA configuration.

Allow configuration of backup settings in MongoDB Custom resource.
This includes management of backed up resources when updating, moving or deleting clusters

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.

> 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

Collect hardware metrics even if there's no managed mongo process

Have Automation Agent collect hardware metrics on unmanaged mongo hosts.

Automation agents doesn't collect hardware metrics unless there's a managed mongo process. This means we can't provide centralized system monitoring for a heterogeneous environment, where some clusters are running on their own and others are under automation, or on any non-managed host.

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