Ops Tools
-
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…
20 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 -
Configure Ops Manager LDAP Auth via an API call
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.
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.
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 -
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 -
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 -
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 -
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 -
10 votes
-
Do not download EOL releases
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.
9 votes -
Encrypt Password LDAP Query User
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.
8 votes -
Add Timezone support to Ops Manager Application logs
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.
8 votes -
Deploy Changes without restarting mongod/mongos instance immediately.
Whenever we want to make changes, eg. set a new parameter or add new parameter in configuration (advance configuration options), after we save changes, review and deploy, automation immediately starts applying that change and does a rolling restart.
We need flexibility in restart, means one should have an option to perform immediate rolling restart or defer it to later time. We may apply multiple changes at different times and set one preferred window to restart instance instead of doing multiple restarts.7 votes -
Ops Manager API call for Host Mappings
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.
7 votes -
Add collection level statistics to the measurements API
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.
7 votes -
Ability to customize subject line for System & Global Alerts
Currently there's no way to customize the subject line of either a system or global alert. The subject line only has the project name & time. It doesn't even say why the alert was generated until the email alert is opened. Having the ability to modify the subject line, even if it's to certain predefined fields such as alert condition for example would be helpful in addressing alerts in an efficient and effective manner.
7 votes -
Add addition authentication mechanisms to the Ops Manager Alerting webhook
Capability to use JWT or SSL certs would be great.
6 votes -
Weekly alerts report as part of the UI
Weekly alerts report as part of the UI with the option to download export to pdf
6 votes -
Consider supporting the installation of mongosh via Ops Manager/automation agent
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.
6 votes
- Don't see your idea?