When trying to implement Atlas infrastructure for Organization/Project users, the Teams functionality is useless unless we can add pending users to a Team. Right now, if a new user doesn't login for two weeks, we can't assign them to a Team until two weeks after the implementation was supposed to be configured.

Provide Peering support for "Classic" (Hub and Spoke) VNet Peering topology, either directly or via a NAT

Here are some suggested functionalities
- Import and export of bulk documents.
- Quickly filter and sort the required documents. (This is achievable in Compass but not in Atlas UI)

The Disk IOPS graph shows 2 colored lines. (read/write). It would be great to add a third line which is the SUM of the 2 lines. Or... a toggle switch so we can see the sum line instead of the 2 components. Thanks!

Session timeout value in Atlas UI defaults at 12h. Allow it to be configurable per Project or Organization, with the minimum value being 15 minutes. All Atlas users within an organization that have been idle for the duration of the configured session timeout should be automatically logged out.

Make EBS Burst Balance Metrics available within the Atlas UI. Currently it is not easy to 100% understand how much burst credits are being used and whether they have actually been depleted.

You can infer it from the IOPS metrics going above baseline IOPS and then suddenly dropping down but would be better to see the balance itself to be 100% sure. This will save support requests to do so.

The speed at which usable monitoring metrics data (1m, 5m) is purged and reduced to 1hr is way too quick.

After 1hr, the ability to analyze these metrics that are crucial to investigating a performance issue were lost and hindered the root cause analysis.

I would suggest that 1m or at least 5m resolution metrics be retained for at least a week before being purged.

This is a request to support an integration with Dynatrace for monitoring MongoDB deployments in Atlas.

Atlas clusters don't support the setParameter command and, as a result, users aren't able to configure log levels. I understand the reasoning behind not exposing permissions to run setParameter to DB users so, in lieu of that, it would really helpful if Atlas users were able to configure log levels through the Atlas UI, preferably at the Node or Cluster level.

Thanks!

Since Atlas clusters now support different sets of hostnames, it would be good to explore the feasibility of allowing users to add their own hostnames to the cluster configuration and TLS certificates such that custom connection strings can be used.

One use case for this is being able to "wrap" Atlas connection strings, such that an application's connection string would never need to change despite underlying cluster changes (cluster being moved between projects, etc.)

This could also be useful if you wished to whitelabel your cluster.

It would be useful to provide the profiler an "allowlist" and "denylist" of users to watch queries from. Essentially, it is only useful to receive alerts and profiler reports for queries made by actual applications. It is not useful to have alerts show up for one-off queries made by a DB admin using a DB explorer.

When a cluster is changed due to auto scaling a message is sent to all project members. Project member cannot unsubscribe to this.
Request :
Provide the option, like all other alerts, to change the the alert settings for auto scaling

Atlas Monitoring UI is great, but to ease centralization of alerts and dashboards..., it would be nice to have all atlas metrics in Cloud Monitoring too.

Under hardware metrics for a given replica set, there is a metric for "Util %". It is unclear on what this represents. After careful digging through the documentation, it appears to be a metric for Disk Bandwidth Utilization. I believe the metric name should be updated to reflect at least "Disk Util %", if not something more specific.

If I already have Cloud Manager backups, or can take an EBS snapshot, I want to be able to quickly Live Migrate this replica set to minimize migration time and load on my existing infrastructure.

We have a platform (as code using Terraform) where we integrate Mongo Atlas in AWS. We have multiple teams with various privileges who access the Mongo Atlas console daily basis. We would always like to manage the users in our version control. As Terraform is one of the best infrastructure configuration tools, we would like to have a terraform resource in order to manage the users via.