Ops Tools
469 results found
-
Add Ops Manager's Org ID/Org Name/Project Name into Project/Global Alerts API calls & Alert Webhooks
What is the problem that needs to be solved? Ops Manager's Org ID/Org Name/Project Name attributes needs to be added to Project (
GET /groups/{PROJECT-ID}/alerts) / Global (GET /globalAlerts) Alerts API calls and Alert Webhooks.Why is it a problem? (the pain) Ops Manager's Org ID/Org Name/Project Name attributes are currently missed in Project (
GET /groups/{PROJECT-ID}/alerts) / Global (GET /globalAlerts) Alerts API calls and Alert Webhooks. Operator who watch Monitoring System (the one that receive Ops Manager Alerts) needs to see Ops Manager's Organization ID/Organization Name/Project Name in order to quickly understand to…4 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 to configure separate SNMP v2C community for SNMP v2C Heartbeat Traps and SNMP v2C Alert Traps
What is the problem that needs to be solved? Allow to configure separate SNMP v2C community for SNMP v2C Heartbeat Traps and SNMP v2C Alert Traps.
Why is it a problem? (the pain) As of now (2020-03-24) there's no way to configure separate SNMP v2C community for SNMP v2C Heartbeat Traps and SNMP v2C Alert Traps (
snmp.communitycontrols both, Heartbeat and Alert Traps sent from Ops Manager's Application Server), some SNMP Monitoring Teams require different SNMP v2C communities for different set of SNMP v2C Traps (to separate Heartbeat Traps and Alert Traps).2 votes -
Allow Point-In-Time restores going back to a configured amount of hours/days
What is the problem that needs to be solved? Allow Point-In-Time restores going back to a configured amount of hours/days (similar to Ops Manager).
Why is it a problem? (the pain) Oplogs are captured for the last 24 hours only, and sometimes the requirement is to be able to execute Point-In-Time restores for longer than 24 hours (48 hours, etc. (to be defined by customer's project/goal)).
2 votes -
Snapshots taken by Ops Manager Backups should include config file
When restoring a snapshot through Ops Manager, automation will create the config file for you. But if you're restoring a snapshot manually, there's no config file! Surely we can include a sample
mongod.confwithe sufficient information filled out to help a user get up and running again.6 votes -
Collect hardware metrics even if there's no managed mongo process
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.
8 votes -
Allow honorSystemUmask to be set on Ops Manager HEADDBs
If honorSystemUmask is set to false, new files created by MongoDB have permissions set to 600, which gives read and write permissions only to the owner. New directories have permissions set to 700.
As a result it makes it difficult to read the HEADDB logs in some environments. Allowing honorSystemUmask to be configurable would allow the customer to choose permissions based on their own security policies.
2 votes -
Allow to configure `maxTimeMS` for commands executed from Ops Manager's Data Explorer
What is the problem that needs to be solved? Allow to configure
maxTimeMSfor MongoDB commands which are executed from Ops Manager's Data Explorer.Why is it a problem? (the pain) A) Ops Manager's Data Explorer cannot work with views in case if the view is taking >15000 ms to be load. Data Explorer cannot work with find operations in case if that find operation is taking >15000 ms to be completed.
6 votes -
List shards in Deployment > Metrics' shard list in alphabetical order
List shards in Deployment > Metrics' shard list in alphabetical order in Cloud Manager UI.
3 votes -
Add Ops Manager check to prevent making backups of itself (Backing databases - AppDB, Oplog, Blockstore)
Otherwise, an Out Of Memory condition may result and disable Ops Manager.
5 votes -
Add Global MongoDB Agent Upgrade ability
Add the ability to upgrade all MongoDB Agents across all Projects at the same time instead of clicking on the banner for each Project.
6 votesWe are going to expose this via mongocli first as it would probably makes a fastest solution.
-
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.
44 votesHi All,
We are developing a solution directly in Ops Manager that will support swapping their S3 snapshot storage without terminating the backup. Ops Manager will allow you to update the S3 snapshot store ID in the backup job document and the next scheduled snapshot will be a full snapshot in the new S3 snapshot store after the update. This is specifically for S3 stores only at this time.
We are targeting this feature to be included in a minor release of Ops Manager 8 by mid 2025 at this time.
I will update this feedback item once launched.
-
Add `serverStatus.uptime` counter info into Metrics
What is the problem that needs to be solved? We already collect
serverStatus.uptimecounter info from each and every MongoDB Server process, so we just need to addserverStatus.uptimecounter info into Metrics so that it will be possible to trackserverStatus.uptimechanges through the time.Why is it a problem? (the pain) If you'd like to calculate MongoDB Server process availability to know for how long your MongoDB Server process(es) was/were up and running, you'll need to analyze MongoDB Server process logs (in case if they are ever available for required period of time) to see last time MongoDB…
7 votes -
Group Host Mapping IPs to be added by default to Programmatic API Keys IP Whitelisting
As part of the Programmatic API Keys introduced in MongoDB Ops Manager 4.2, it would be good to have the IPs listed in the Host Mappings of a Project Deployment to be added as default whitelisted IPs when setting up a Programmatic API Key for same Project.
2 votes -
Single Project Programmatic API Keys should not require Org User Admin role for IP Whitelists update
When setting a Programmatic API Key in the MongoDB Ops Manager for a given Project, it seems Project Owners are unable after setting the Key to update the IP Whitelist as they require Organization User Admin role to perform such action (screenshot attached).
I guess this makes sense if the same Programmatic API Key is shared between multiple Projects inside the same Organization, but not really if this is applied only to one single Project (i.e. Project Owners should be able to amend the IP Whitelisting of their own API Keys).
I wonder if this could be enhanced in further…
4 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_DOWNalert 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
DOWNstate. Missing<HOSTNAME>:<PORT>information at.1.3.6.1.4.1.41138.1.1.1.4SNMP OID does not allow user to mapAUTOMATION_AGENT_DOWN,MONITORING_AGENT_DOWN,BACKUP_AGENT_DOWNalert types into a particular hostname.18 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.
22 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.
13 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…
16 votes -
Add configuration option to disable seedSecondary scripts in snapshots
Currently each snapshot includes the seedSecondary scripts that no longer work for MongoDB 3.6 or greater.
-r-x-w-r-t 1 107 65534 767 Jan 30 11:40 seedSecondary.sh -rw-r--r-- 1 107 65534 754 Jan 30 11:40 seedSecondary.batPlease add an option to disable adding these files to snapshots or remove them completely as they are deprecated for MongoDB 3.6+.
2 votes
- Don't see your idea?