Ops Tools
462 results found
-
Option to clear deleted alerts
Deleted alert definitions pile up in the "deleted alerts" tab of Ops Manager.
This information may be useful for auditing purpose, but in the long run, the number of deleted alerts may grow too large. Especially in our use case, where alert configurations are deployed through a script that deletes/recreate all alerts.
Feature suggestion: add an action to clear all deleted alerts (or better: clear all deleted alerts older than N days).
2 votes -
Support kubernetes taints and tolerations
I believe kubernetes taints and tolerations are not supported by the operator, yet I find it a much needed capability.
1 vote -
mongorestore from metadata
hi
When start mongorestore, data is restored first.
so, performance is poor, and recovery takes a long time.
would please proceed from the metadata(index) and change it so that it can be restored quickly.as-is: data > metadata(index)
regards,
park1 vote -
connection-pool monitoring
hi
like this, would you please support connection-pool monitoring.regards,
park1 vote -
Allow informational alerts to be sent to PagerDuty
Right now informational alerts can't go to PagerDuty, OpsGenie, or VictorOps. Ideally all alert notifications should go to the same endpoint, even if those alerts are "informational" and no acknowledgement is required.
2 votes -
Never delete the most recent backup snapshot
When backup snapshots cannot be completed as scheduled, and they are behind, Ops Manager really should NEVER delete the most recent snapshot. For example, if the snapshot retention policy is to take a backup every 24 hours and keep daily backups for 2 days, and weekly backups for 2 weeks, a new snapshot should not automatically expire after 2 days. If backups are not completing for some reason, and it goes 2 days without a successful new snapshot, the most recent daily backups are deleted and we are left with the most recent weekly backup instead. There really should never…
3 votes -
MongoDB Operator Deployment Env Variables Push Down
This is a feature request to have custom environment variables, configured in the MongoDB Operator's Deployment manifest, push down or propagate to all resources created by the Operator.
For example, it may be desired to add environment variables with context. A more specific example could include setting a TZ timezone environment variable that is automatically added to all pod containers created by the Operator.
2 votes -
arm64 support for Cloud Manager Agent
We would like to install Cloud Manager Agent on arm64 based linux machines.
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.
11 votes -
Drag and drop
This is strictly cosmetic, but in Ops Mgr Deployment->Processes->deployment, it would be nice to be able to drag-and-drop the order of the servers. I believe it shows them in the order they were added to the replica set, the same as rs.status() or rs.config() would show, but for our deployments, we typically have 2 "main" systems, and then a third "DR" system. It would be great if I could always have our main systems as the first 2 systems, and then our "DR" system last, regardless of how they were added to the replica set. The order they were added…
1 vote -
Restore Backup Snapshots to Sharded Clusters via mongos
Migrating large sharded clusters to a different cluster pre-sharded with different shard keys requires a significant amount of time to balance post-restore.
This is a feature request to restore a snapshot on a per document basis through a mongos. The desired result is a completed restore with collections/documents residing on their target shards.
5 votes -
The Project Global Admin Agent logLevel settings are redundant and confusing
As explained here:
https://docs.opsmanager.mongodb.com/current/tutorial/manage-project-settings/index.html#admin-project-settingsThe Ops Manager global admins can override the logLevel setting on a project for Automation and Monitoring Agent modules using the webUI.
This will cause the Agent to override the local config logLevel setting to what's set in the webUI.
Please note that this global admin project setting is redundant as the logLevel of the Agent modules can be also set by using the "Edit custom configuration" window in the project agent settings page as explained here:
https://docs.opsmanager.mongodb.com/current/reference/mongodb-agent-settings/#configuration-file-settings-locations1 vote -
Allow to create custom roles
Allow to create custom roles for Atlas/CM/OM
4 votes -
Add command for upgrade a cluster
Currently there is no easy way to upgrade a cluster but we need to modify the file describing the cluster and push the full description.
Would be nice to have a command like:mongocli om upgrade --version "4.2.10" --fcv "4.2" MyReplicaset
4 votes -
Create a User in a Single Cluster
When multiple clusters are added into an Ops Manager project, the only way to create a user account is to add it to all of the clusters in the project and to then add server IP Address restrictions to prevent the user from logging into servers other than the intended cluster. This would still create the user account on all of the clusters in the Ops Manager project.
Users would need a way to create a user account on a specific cluster rather than all of the clusters of the project.
2 votes -
1 vote
-
There is currently no way to use the UI to search a given hostname at a Global Level within an Ops Manager deployment.
Please provide a feature in OM so we can search globally a given HOSTNAME to know about its related Organization/Replica Set
2 votes -
As a DBA using Ops Manager, when I make a cluster or project change (eg. enabling LDAP), I'd like to see a "dry run" of potential impact
As a DBA using Ops Manager, when I make a cluster or project change (eg. enabling LDAP), I'd like to see a "dry run" of potential impact like a brief outage so that I will know that this change will have an impact on my end users or not. As of right now, when I make a change, it just happens to all projects/clusters immediately and may create a non-scheduled outage.
1 vote -
I need another level of granularity with RBAC grouping so that only the users of database can see that data.
As a Ops Manager Admin, I need another level of granularity with RBAC grouping so I can have organization, project and subproject permissions. I currently have hundreds of users in a project level and the permissions are too wide.
1 vote -
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
17 votes
- Don't see your idea?