Ops Tools
469 results found
-
mongomirror compatibility with SRV strings
It would be ideal if the mongomirror utility could accept SRV-based connection strings for the source and destination clusters. The inability to do this can cause pain for customers. For example, this does not work:
--destination "mongodb+srv://mgo-aura-dgs-prdsrv-tk-pl-0.yrmiy.mongodb.net"
So users are stuck doing this:
--destination "atlas-nkaylx-shard-0/pl-0-ap-northeast-1.yrmiy.mongodb.net:1036,pl-0-ap-northeast-1.yrmiy.mongodb.net:1037,pl-0-ap-northeast-1.yrmiy.mongodb.net:1038"
Two issues with that:
1. It's painful looking up the host/port and atlas defined replica set name
2. The destination info is unreadable by most humans. The service name (i.e. SRV record connstring) includes the name of the cluster that the customer defined, and not the random has that Atlas generates2 votes -
Configure MongoDB Automation Agent collecting stats on some collection to not trigger alerts
We just had a support case about some alerts being raised on our cluster because the MongoDB Automation Agent collecting stats on some collection doing queries without index triggers "Scanned Objects / Returned" ratio has went over 1000.
It would be really nice to at least not raise alerts when it's the mongodb automation agent that triggered it. Were monitoring our alerts a lot and these are false positive we can't do anything about it seems other than create all the indexes it needs, which might change over time. We have no guarantee of which index it needs.
Another alternative…
9 votes -
index review before sharding with OPS Manager
Currently, when you use OPS Manager to shard a collection, it automatically creates a foreground index that exactly matches the sharding key, when such index doesn't exist. When the sharding key column(s) is(are)already prefixing an existing index, it's not sufficent.
This is dangerous in Live environments because the whole database is blocked for a long time (sharded collections are usually big collections).
So, several features could exist :
- before continuing with sharding, OPS Manager warns that it needs to create this foreground index first. You can stop if you don't agree (and create this index by yourself first).
-…5 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.
43 votes -
avoid generating alert with error message if one oplog node in replicaset got rebooted.
currently if one of the node in appdb/oplogdb goes down for any reasons (for example, linux patch rebooting the node), ops manager generates alert
"Ops Manager was unable to connect to this database and run the
pingcommand. The database could be down, unreachable, or running with authencation and Ops Manager does not have adequate permissions."there are still 2 other running nodes in replicaset. so this alert is misleading and generates false alarms.
2 votes -
Add compound indexes support for Ops Manager managed Sharding
What is the problem that needs to be solved? Ops Manager Automation does not take into account compound indexes (https://docs.mongodb.com/manual/core/index-compound/), e.g. if we have
{ a: 1, b: 1 }index already exist Ops Manager will still create{ a: 1 }index foraShard Key.Why is it a problem? (the pain) This creates unnecessary indexes with performance impact on the MongoDB Server process.
2 votes -
Request Logs - Add timeframe to list of options
While diagnosing historical issues "Request Logs" does not allow for selectable timeframes. As such, for these issues, logs must be manually gathered. Adding an optional timeframe will assist in diagnosing issues much faster.
3 votes -
S3 Snapshot Store Speed Test
It is often quite difficult to diagnose latency/bandwidth/generally slow S3 storage. It would be useful if Ops Manager could run a short test to show:
- How fast a single large object can be PUT and GET
- Measure parallel PUTs and GETs against test objects
- How much latency there is between Ops Manager and S3
1 vote -
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
- Don't see your idea?