Ops Tools
462 results found
-
Significantly Throttle or Skip MongoDB Agent Connections to Intentionally Disabled Clusters
When performing an automated snapshot restore in Ops Manager, the MongoDB Agents shut down all MongoDB cluster members while the snapshot(s) are downloaded to the dbPath's.
During this phase of the plan, the MongoDB Agents continue to attempt network connections to the cluster members; as frequently as ~4 per second per mongod. This traffic may pose problems for certain cluster deployment designs. Of note, clusters that are "micro-sharded" (multiple cluster members residing on the same physical hosts) and clusters with members in a remote datacenter can receive an amplification and/or excessive amount of connections relative to what the network can…1 vote -
In Ops Manager, the user show as all deployment. How can i change from 'all deployment' to a specific deployment.
In Ops Manager, the user show as all deployment. Using MMS, How can i change from 'all deployment' to a specific deployment.
MongoDB User Name MongoDB Roles Deployment
yyyyy xxxx-rw@xxxx all deployments1 vote -
Allow additional port for SMTP configuration
Our Cyber team doesn't want SNMP traffic on default port, need dev team's help to enable additional (or custom) ports to be setup in SMTP configuration (e.g. port 163).
1 vote -
Automation - Improve import for automation when keyfile doesn't match
Starting with MongoDB 4.2 we are able to rotate the internal authentication keyfiles in a rolling fashion with the procedure described here:
https://docs.mongodb.com/manual/tutorial/rotate-key-sharded-cluster/Currently when you import for automation a cluster that is using a different keyfile than the one in the automation config a bouncerestart is triggered. We can avoid it by doing a rolling rotation of the keyfile.
The old keyfile should be kept and the new one appended to it in a rolling fashion. We may have already this implemented for the "Rotate keyfile" feature present in the Security tab page.
4 votes -
Make snapshot retention policy more customisable
Make the retention policy of Ops Manager snapshots customisable so we can choose custom values (like 21) to be more flexible with the settings.
11 votes -
Mark IP ranges when user add to whitelist more than 4 address network
Security/Network Access/IP Access List
When adding the ip range it is easy to make mistake an example instead of 192.168.5.5/32 add 192.168.5.5/3
It will be great to mark as read or ask user "are you sure to add range with mask <30"
1 vote -
Grant permission to access Real Time tab to Project Read Only users
Accessing the Real Time metrics tab requires at least the Project Monitoring Admin role but this role has other privileges to administer alerts and manage hosts as well.
It is more appropriate to enable the read-only access user (Project Read Only role) to access the Real Time metrics tab.
4 votes -
integration with Mattermost for notifications
It would be good to replicate the integration with Slack but using Mattermost. Mattermost is open source and allows the companies to deploy their own messaging server. Some organizations are moving from Slack to Mattermost for this reason.
2 votes -
Filter/Sort Process List View
In previous versions of Ops Manager, you could filter the process list page. It would be nice to bring that back, so we could quickly identify processes which do not have recent pings, etc.
3 votes -
adminCredentials secret should always be source of truth for OpsManager
The secret is only taken into account by OpsManager initially when OpsManager is deployed. As soon as the password of this user is changed in OpsManager, this secret is out of sync.
From the docs: "Use these credentials to log in to Ops Manager for the first time. Once Ops Manager is deployed, you should change the password or remove this secret."
https://docs.mongodb.com/kubernetes-operator/v1.4/tutorial/plan-om-resource/#prerequisitesOption 1: This secret should be in-sync with the OpsManager database. Preferably the sync should be from the k8s secret to the OpsManager database.
Option 2: Create a CRD "MongoDBOpsManagerUser" that handles User/Password management for OpsManager similar…
6 votes -
Periodically notify users of unused versions located in versions directory
As a safety measure for admins in Ops Manager to avoid facing issues due to unnecessary disk occupation under the Ops Manager installation directory:
Send periodic notifications (configurable) i.e: once a month; to notify what binaries are not being used by none of the components in their environment so they can evaluate to delete them in order to free up space on their Ops Manager servers.
5 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 -
To setup number of backup daemons in ops-manager.yaml
In ops-manager.yaml, can we define the number of the initial backup daemons?
5 votes -
Disable the dropdown to add Agent functions on hosts that don't have the MongoDB Agent installed and were only imported for Backup/Monitori
Disable the dropdown to add Agent functions on hosts that don't have the MongoDB Agent installed and were only imported for Backup/Monitoring.
The elipsis (...) selections to add Monitoring & Backup Agent functions are available on hosts without the MongoDB Agent. If selected the function appears on the host as grey and standby. This is misleading. The options should not be available on hosts without the MongoDB Agent.2 votes -
cert-manager & external-dns integration
Since the kube CA integration is deprecated, the operator should have an option to integrate with cert-manager and external-dns for automatic tls and dns records.
1 vote -
Activate multiple monitoring module in appDB monitoring project
On Servers Page, Activate/Deactivate Monitoring/Backup module should be activated. So that multiple monitoring module should be activated for hot stand by.
2 votes -
Store the type of cloud in profile to shorten the CLI command
MongoCLI current requires the user to type on the command-line if it's an Ops Manager, Cloud Manager, or Atlas. We could store this information in the profile (the file containing the URL and API keys) so the users have less to type.
PS: This applies to all 3 categories - MongoDBCLI with Ops Manager, MongoDBCLI with Cloud Manager, and MongoDBCLI with Atlas - on feedback.mongodb.com and the UI forces me to select only one of them
2 votes -
Provide mechanism for internal password rotation of the automation user
Ops Manager automation currently uses an mms-automation user for node management, but the password for that user is set once and stays forever unless it is updated via the Ops Manager API.
This feature would provide a mechanism that allows this password to be re-generated via the UI or an API call and have it automatically updated on the managed mongod instances as well.
11 votes -
Make the option of "security.TransitionToAuth" available through Ops Manager Advanced Configuration Options
Currently the option of "security.TransitionToAuth" is not available in Ops Manager as "transitionToAuth" is automatically added to each node in a rolling fashion by the Automation agent and then ultimately removed when authentication is finally turned on for all nodes.
Allowing this option through Ops Manager will enable the mongod to accept and create authenticated and non-authenticated connections to and from the connected clients. Thus the clients can use this feature to avoid downtime at their end while the connection settings are updated to use the appropriate user to connect to mongod.
5 votes -
Start MongoDB Agent service (`mongodb-mms-automation-agent.service`) automatically after OS restart, make it default behavior
What is the problem that needs to be solved? MongoDB Agent service (
mongodb-mms-automation-agent.service) does not start (by default (disabled; vendor preset: disabled)) automatically after OS reboot.Why is it a problem? (the pain) OS restarts can be frequent, and current default behavior (
disabled; vendor preset: disabled) of MongoDB Agent not to start after OS restart causing additional downtime for customers.3 votes
- Don't see your idea?