Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
180 results found
-
Investigation Buckets (dropdown menu) to enable predefined set of MongoDB & Hardware Metrics to investigate certain Data Layer SLAs
We have many metrics under "MongoDB Metrics" & "Hardware Metrics". User will have a good idea which metrics to enable while troubleshooting certain requirements.
E.g. User is investigating current lags in the data Layer. User has to select all the metrics that would help them get the data they are looking.
We can help the customer bit more by provide buckets like.
Options ( select one )
1. Investigate Lags
2. Investigate IOPS
3. Investigate Replication
4. Investigate Search Index
... and etc..This will pre-select certain metrics from list of Mongodb & Hardware metrics which will give them all…
1 vote -
Atlas metrics granularity after 48 hours
For metrics older than 48 hours, the data is presented in 1-hour intervals. This level of granularity is often too coarse for a thorough examination of past events and trends. Such a broad view can obscure smaller yet significant details critical for understanding and resolving performance issues that occurred in the past.
Suggested Improvement:
having a smaller granularity value for historical metrics beyond the 48-hour timeframe. Providing data in smaller intervals would greatly enhance our ability to conduct in-depth analyses and diagnose past performance issues accurately. This would be particularly beneficial for conducting detailed investigations of historical data and identifying…
5 votes -
Ability to "Mass Kill" slow running queries
Currently, Atlas has a "Kill Op" option which is useful to kill single long-running queries.
When upgrading to MongoDB 7.0, we were faced with a situation where the Slot-Based Query Engine (SBE) was causing 1000s of queries to execute slowly, we wanted to kill them all, but it was more than a human could do by clicking "Kill Op" 1-by-1. Hence a "Mass Kill" feature which kills queries longer than X seconds (X is configurable) would have helped us greatly in an outage scenario. We ultimately rebooted our cluster to kill queries, then manually implemented a script which did this…
7 votes -
Export only selected Atlas metrics
This is a request from a customer named: UPAX partnered with Grupo Salinas.
Inside the cluster metrics, where the Status is displayed, we are able to find the Export option (PDF, PNG) and they would like to export for only specific metrics (only the toggle charts) not the whole of them for reporting purposes with other teams and management.1 vote -
Metric reporting private endpoint state
On Mongo Atlas platform we are able to see the status of both Atlas Private Endpoint and Azure Private Endpoint. It would be helpful to have these statuses available as a metric on the prometheus integration.
4 votes -
Monitoring Metrics on dhandle
We'd like to monitor the WiredTiger dhandle over the time, directly from Cloud Atlas Monitoring view. It would allow to directly see the impact when updating cluster settings.
We'd like also being able to configure alert triggers on it, the goal for us is being alerted when an excessive amount of files (collections & indexes) is loaded into the MongoDB Memory, to avoid reaching an Out Of Memory error.
3 votes -
Duplication detection
One of our custmoers would like to see duplication detection as their project is spread out over various projects.
Value: It is important as different regions create sometimes duplicates and duplicates can be avoided in advance.
1 vote -
Add document count to Datadog metrics
We'd like to monitor the number of documents in a collection via DataDog.
For On-Premise MongoDB the stats are already reported via mongodb.collection.count, mongodb.collection.size and mongodb.collection.avgobjsize.
If the same metrics could be made available for Atlas (E.g. mongodb.atlas.stats.collection.count) that would really help in monitoring.
E.g. spikes in different parts of the application could be tied to the number of documents on a glance. Without having that metric available, it is hard to pinpoint if a recent change had a negative impact on performance.
If the metrics can't be made available on the collection but only on the database level, this…
8 votes -
Metrics: Fix Y axis of "max CPU %" charts to 100%
In the various CPU % usage charts in the shard metrics, it looks like the upper limit of the Y axis isn't fixed, and it changes based on what the maximum value in the range of time being displayed is. For both normalized and regular CPU% values, there's a natural maximum to the value, I think: 100% for the normalized CPU%, and ncores*100% for the non-normalized CPU%.
With a changeable Y limit, it's hard to tell at a glance whether the value is actually really high or not. Oh, the blue line is hovering up near the top of the…
1 vote -
Display all function log messages
Currently we only can see under "App Services > Manage > Logs" section the output of a few log messages for each function execution, but if the function contains a large amount of logs (more than 100 for example) the interface only shows the last log entries, making difficult to debug and check for errors.
There is should be way to see all logs output of a function execution.
Forum reference: https://www.mongodb.com/community/forums/t/atlas-functions-seem-to-not-display-all-of-the-logs-when-running-in-web-ui/194108/6
1 vote -
Change Streams Monitoring and Alerting
Change streams can cause performance issues if not used properly. In some cases, administrators of multi-tenant dbs have no control (and shouldn't) over how various clients create change streams.
I think it is important that we accommodate these use-cases and provide useful metrics in the OM/Atlas metrics pages, and alerts on those metrics. Some potential metrics:
1. Number of change streams open
2. Average change stream lifetime
3. Query targeting ratios for change streams
4. Avg time between consecutive polls of the change stream (and other statistics)
--thought here is that change streams that are polled infrequently will result in…9 votes -
Display "N/A" instead of "0" for doc count in timeseries collection in Compass
In Compass 1.36.4, when I look at a database that has a time-series collection in it, in its list of collections, it displays the collection as having "Documents: 0" and "Avg. document size: 0", even when there are some documents in it.
I think that's misleading. As I understand it, time-series collections do not support the estimated document count functionality that is used to populate these fields in the Compass GUI. That being the case, it might be better to display "n/a" or a blank in those fields, instead of a 0 which is not the correct value. A user…
1 vote -
Integrated/unique metrics vision for primary replica-set
It is really hard to understand the behaviour of primary replica-set on bigger timeframes, when it was switched some times. Would be very helpful to be able to see the metrics in a integrated chart, to understand consequences of some actions like application changes, index creations, version upgrades, etc.
1 vote -
Prometheus database and collection metrics
We checked the Prometheus metrics provided by MongoDB Atlas and didn't find metrics for the following:
Database sizeCollection storage size
Record per collection
Indexes per collection
Index size
We would like to have this kind of metrics to add to dashboards.
25 votes -
Export profiler slow queries via Datadog integration
The "profiler" tab in Atlas is very nice -- it gives a really nice over-all view of slow queries, with the ability to drill down into the individual calls.
However, I don't check this page every day, and so it is sometimes hard to find out when we actually do have slow queries or commands pop up on it if it is not affecting our cluster.
We use datadog as the central point for all of our monitoring. We have the Atlas <--> Datadog integration set up, which exports a number of useful stats. It would be very nice for…
3 votes -
Metric Charts Aggregated by Primary Node at the Time
Providing an aggregated metrics based on the primary server. Right now in order to view history for the primary we have to compare the different charts based on failover, makes it cumbersome to view the active primary trends
1 vote -
Use additional metadata to differentiate processes
Right now Ops Manager monitoring identifies MongoDB processes according to hostname:port. Unfortunately, if 2 processes have the same short hostname & port in the same Ops Manager project, they'll be treated the same even if they are actually different processes with different FQDN.
Please either allow the use of additional characteristics (FQDN, replica set name, config server name, etc) for differentiating MongoDB processes or provide some way to tag 2 or more processes so monitoring doesn't accidentally miscategorize them as the same process.
2 votes -
Display Total Cluster Data Size in Atlas UI
Atlas doesn't display the total data size of the databases hosted on the sharded cluster. This feature was available in Opsmanager and will be very helpful for the DBA's and the product development teams to glance at the data size of the cluster.
Attached the screenshot for example.
Nice to have or display the size of each database and also display the historical datasize metric for each database in a sharded cluster.
3 votes -
Minimum Oplog Retention Period - Set Minimum Oplog Window
The documentation states: "New in version 4.4: Starting in MongoDB 4.4, you can specify the minimum number of hours to preserve an oplog entry." https://www.mongodb.com/docs/manual/core/replica-set-oplog/#minimum-oplog-retention-period
The mongodbatlas_cluster resource in the terraform mongodbatlas provider only provides for the oplog_size_mb argument. https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/cluster#oplog_size_mb
It would be nice to have that exposed so that terraform can update that value.
1 vote -
Basic operational metrix support with instana and grafana
Hi MongoDB Team,
We are using grafana and instana SRE tools for application monitoring.
But MongoDB did not exposing the basic statistics like Total number of records and record insertion / updation / selection rates (over a sepcific period of time ) with grafana and instana .
Kindly note that grafana and instana are widely used as industry standard SRE tool and it will be really helpful if MongoDB team could also expose these kind of detailed statistics with grafana and instana.
I would request you to prioritize this request since lack of these reports is creating an empty space…
1 vote
- Don't see your idea?