Ops Tools
-
On demand snapshots in Ops Manager
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.
44 votes -
Deploy MongoDB across different Kubernetes clusters
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.
39 votesThis feature is in beta: https://www.mongodb.com/docs/kubernetes-operator/master/multi-cluster/
-
Add the ability to trigger alerts for testing purposes
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.
22 votes -
Allow Ops Manager users to move/migrate backup job snapshots from one S3 bucket to a different S3 bucket
Ops Manager users with S3 blockstores may need to move snapshots and backup jobs to a new S3 bucket. For MongoDB blockstores, this is accomplished using a groom.
Move Blocks to a Different Blockstore
https://docs.opsmanager.mongodb.com/current/core/administration-interface/#groom-priority-pageThis feature request is to provide the same feature to groom backup snapshots/jobs to a new bucket for S3 blockstores.
20 votes -
Provide recurring/daily reporting on backup status from Ops Manager
Ops Manager should generate a recurring/daily report of the status of all backups. This report should include at least a list of successful snapshots, a list of unsuccessful snapshots (over the configured reporting period), and the latest successful snapshot for each deployment being backed up. Additionally, this report may include resource availability such as storage available for future snapshots.
20 votes -
Support migrations to different snapshot stores
Currently it is not possible to transition between snapshot store types.
There are two options currently when transitioning to the new one.
- Terminate backups (deleting all previous snapshots)
- Create a new project and abandon the previous one to allow automated restores at a later time
Both of these options are difficult to manage for large deployments. The first option requires you to store the snapshots elsewhere and disallows automated restores. The second option requires many operations and clutters the Ops Manager project list.
Ideally we should be able to transition from any store location/type to any other location/type. One of…
19 votes -
Add support for virtualization volume management in Ops Manager Backup snapshots and restores.
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).
17 votes -
Ops Manager: Test Failover
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.
15 votes -
SNMP traps for `AUTOMATION_AGENT_DOWN`, `MONITORING_AGENT_DOWN`, `BACKUP_AGENT_DOWN` alert types does not contain hostname information
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 mapAUTOMATION_AGENT_DOWN
,MONITORING_AGENT_DOWN
,BACKUP_AGENT_DOWN
alert types into a particular hostname.15 votes -
Show time it took to complete a snapshot
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.
14 votes -
add details to alert Query Targeting: Scanned / Returned to identify what triggered it
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.14 votes -
14 votes
We are about to start working on signing our images with Docker content Trust.
-
mongo push
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.
13 votes -
Add the ability for the backup daemon to download and validate snapshots
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.
13 votes -
Headless OPS Manager deployment
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
12 votes -
Automated restores between multiple Ops Manager deployments
Ability to utilize API and/or UI to restore a snapshot downloaded from one Ops Manager deployment to a separate distinct Ops Manager deployment.
Some environments require separation of Production and Staging systems, including Ops Manager deployments. It is desirable to use Production data in some testing scenarios. Currently the data has to be loaded or restore manually.
12 votes -
Add Ops Manager's Org ID/Name into all SNMP Alert Traps
What is the problem that needs to be solved? Ops Manager's Org ID/Name is not included into any of SNMP Alert Traps sent from Ops Manager's Application Server.
Why is it a problem? (the pain) Operator who watch Monitoring System (the one that receive SNMP Alert Traps from Ops Manager) needs to see Ops Manager's Organization ID/Name in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive SNMP Alert Traps from Ops Manager) needs to do additional work for each SNMP Alert Trap received (via
GET /groups/{PROJECT-ID}
/GET /orgs/{ORG-ID}
…11 votes -
Allow assignment of Backup Resources before starting Backup Job
For very large clusters, ideally backup resources should be assignable before the backup begins. For each shard and config server, assignment of the following would assist in scaling Ops Manager backups.
- Snapshot Store
- Oplog Store
- Backup Daemon (if using FCV <= 4.0)
Starting the backup could trigger an email to the Backup Administrator who could then assign these resources on the Admin page.
11 votes -
Change namespace option on mongomirror
I was wondering why you can migrate data but you actually (as far I as saw) cannot change the database name during the process of migration (not using mongod/mongorestore unix/win commands but Atlas directly).
From the technical support:
"This is because Live Migration using mongomirror as an underlying process, which in this case tails the oplog and recreates the data exactly as is. This tool is typically used to minimize downtime, especially in production environments, for users who are migrating their data as is while writes are still occurring on the source instance. "
However, as I responded:
"Ok thanks…
11 votes -
Apply Project Maintenance Windows to Global Alerts
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.
10 votes
- Don't see your idea?