1332 results found

1. Profiler should only watch queries from certain users

   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.

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Being able to change the cluster name

   a cluster has been in development for awhile .. but as new cluster are created within the project.. we'd like to change the cluster name ..

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Rename Hardware Metric "Util %"

   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.

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Show a graph of BANKED iops (AWS)

   Atlas monitoring is great... but it would be super helpful to see a graph of banked iops. (or an approximation of this)

   Suppose my iops limit is 100... and during the night my bank gets fully charged to 5.4MM.
   During the heavy loads on my server, let's say my iops jump to a steady 500. This means that I am drawing 400 units from my bank. I can do this for 3.75 hours until my bank is exhausted.

   It would be so helpful to see an iops bank balance drawing down during peak, recharging during off-peak... and thus getting insight as to when we need to scale up.

   Atlas monitoring is great... but it would be super helpful to see a graph of banked iops. (or an approximation of this)

   Suppose my iops limit is 100... and during the night my bank gets fully charged to 5.4MM.
   During the heavy loads on my server, let's say my iops jump to a steady 500. This means that I am drawing 400 units from my bank. I can do this for 3.75 hours until my bank is exhausted.

   It would be so helpful to see an iops bank balance drawing down during peak, recharging during off-peak... and thus getting insight… more

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. More detail and lead time around maintenance notifications

   When we get email notifications of upcoming maintenances, it doesn't specify if the update is "urgent" or "low". When we received our last notice, it was 3 days out. If it's urgent, then we understand the short time frame around the notice. However, if it's a lower priority update, I would hope we could configure how far out we are aware of the maintenance or at a minimum get notified 2 weeks prior so we can communicate to our end users.

   Additional information around what the maintenance is for would be appreciated as well. Something along the lines of "Patching to 4.0.14" or "OS level updates". In general, we are in the dark in regards to what is being updated.

   When we get email notifications of upcoming maintenances, it doesn't specify if the update is "urgent" or "low". When we received our last notice, it was 3 days out. If it's urgent, then we understand the short time frame around the notice. However, if it's a lower priority update, I would hope we could configure how far out we are aware of the maintenance or at a minimum get notified 2 weeks prior so we can communicate to our end users.

   Additional information around what the maintenance is for would be appreciated as well. Something along the lines of "Patching… more

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   5 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Support for Push-Based Logging to Azure and GCP

   Asking on behalf of customer, please add Support for Push-Based Logging to Azure and GCP instead of just to AWS S3 buckets: https://www.mongodb.com/docs/atlas/push-logs/

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Allow customization of where $merge creates the temp collection used when rehydrating data from Online Archive --> Atlas

   When you restore data from the Online Archive back into your Atlas cluster (aka "rehydrate") you need to use $merge within an aggregation pipeline. What isn't documented is that $merge will create a temporary collection in the same database you're rehydrating to, which requires that you have readWrite@<dbName> privileges so that the new collection can be created.

   For customers that operate on the "principle of least privilege," where you only grant literally exactly what is needed to accomplish database CRUD operations, the user would the more narrowly scoped "readWrite@<dbName>.<collName>" privilege granted to the user to scope the actions to only the collection itself, thus not opening up readWrite capabilities for other collections in the same DB. For those customers, the $merge will fail with an error like:

   MongoServerError: failed to execute $merge into <DB>.<COLL>: not authorized on <DB> to execute command { aggregate: "tmp.agg_merge.d8af7e12-3f40-4b9c-b0b8-a9aef271a89f", allowDiskUse: false, comment: "via Atlas Data Federation, correlationID = xxxxxxxx", pipeline: [ { $merge: ...

   Since those narrow privileges won't permit the creation of the "tmp.agg_merge.<UUID>" collection within the DB they're rehydrating data to. Adding an option to the $merge aggregation stage that would allow the customer to control which DB the temp collection is created in, or to explicitly specify fully namespace of the temp collection (so that they can pre-grant the privileges needed for the user within Atlas) would allow customers to not have to violate internal security policies in alignment with the "least privilege needed" paradigm.

   When you restore data from the Online Archive back into your Atlas cluster (aka "rehydrate") you need to use $merge within an aggregation pipeline. What isn't documented is that $merge will create a temporary collection in the same database you're rehydrating to, which requires that you have readWrite@<dbName> privileges so that the new collection can be created.

   For customers that operate on the "principle of least privilege," where you only grant literally exactly what is needed to accomplish database CRUD operations, the user would the more narrowly scoped "readWrite@<dbName>.<collName>" privilege granted to the user to scope the actions to only… more

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Online Archive  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Atlas - Queue cluster pause request to perform it when it's possible

   It is impossible to pause a cluster that was recently resume.

   The documentation indicates it is a voluntary feature (https://www.mongodb.com/developer/products/atlas/pause-resume-atlas-clusters/) to allow the Atlas service to apply any pending changes or fixes to the cluster that may have accumulated while it was paused.

   I agree with this, but it cause a problem for automation (for example sometimes we launch a platform exclusively for testing purpose and then shut it down, it is complicated to add a delay for pausing the Atlas cluster) and even manually for example at the end of the day of work this requires either staying later just to replay the pause or leaving the cluster running all night for example.

   I want to suggest you to improve this feature by recording the pause request and applied it once you finished your maintenances. You might introduce a new cluster state (terminating ?) to show to everyone that the cluster will be paused in few time.

   It is impossible to pause a cluster that was recently resume.

   The documentation indicates it is a voluntary feature (https://www.mongodb.com/developer/products/atlas/pause-resume-atlas-clusters/) to allow the Atlas service to apply any pending changes or fixes to the cluster that may have accumulated while it was paused.

   I agree with this, but it cause a problem for automation (for example sometimes we launch a platform exclusively for testing purpose and then shut it down, it is complicated to add a delay for pausing the Atlas cluster) and even manually for example at the end of the day of work this requires either… more

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Allow private dns names for Atlas private endpoints

   When a customer requires the use of private DNS names for their Atlas private link connection strings, can we allow them to switch on this capability? Basically use a private dns zone instead of a public one and share it as part of the VPC endpoint setup? AWS seems to offer this capability. See this link here https://aws.amazon.com/about-aws/whats-new/2020/01/aws-privatelink-supports-private-dns-names-internal-3rd-party-services/

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Serverless instances on AWS South American region

    It will be nice to have serverless instances on AWS South America. This model is great for this region and I strongly believe that it can have a lot of demand.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  Serverless Instances  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. change streams serverless

    Hi. I need the "change streams" feature implemented for serverless deployments.

    At this time it's unclear when will it be implemented, hence it's difficult to plan ahead.

    Why is that important?
    My nodejs app relies on change streams. Without it - the app simply cannot start because basic functionality is missing.

    Our devteam maintains a few complete vertical qa/testing stacks. Developers/QA/Product people load their change into these stacks and share with others. They are then used for product UI validation, sanity/automated testing etc.

    Because the app depends on change streams, those stacks are restricted to use only production Atlas clusters.

    The bandwidth and performance required from those stacks is miniscule. Using the production clusters is not cost effective (and waste of hw resources!).

    My understanding is that the Serverless deployments were created exactly for this reason. However for us they are completely useless unless to us they support change streams.

    Please update re the feature's expected timeline.

    Hi. I need the "change streams" feature implemented for serverless deployments.

    At this time it's unclear when will it be implemented, hence it's difficult to plan ahead.

    Why is that important?
    My nodejs app relies on change streams. Without it - the app simply cannot start because basic functionality is missing.

    Our devteam maintains a few complete vertical qa/testing stacks. Developers/QA/Product people load their change into these stacks and share with others. They are then used for product UI validation, sanity/automated testing etc.

    Because the app depends on change streams, those stacks are restricted to use only production Atlas clusters.

    … more

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Serverless Instances  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Support Slack in Third Party Integration

    Slack is supported via UI or API, but not via the Terraform Provider (v1.3.1).

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    3 comments  ·  Terraform Provider  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Allow registering multiple security keys in MFA

    Currently, only a single security key can be registered as an MFA device. As a backup to this key, only other mechanisms such as authenticator apps can be used. It would be nice if multiple keys could be registered to avoid having to use a different method as the backup.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. serverless

    Can we have a way to stop going over a certain amount RPU/WPUs, i know we can have alerts but we should be able to say dont go above a certain amount or somehow limit usage.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Serverless Instances  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Improve the "host is down" alert by eliminating false positive alerts

    Currently, whenever an index build is kicked off on a replica set, it tends to trigger a "host is down" alert. Although this is benign and a false positive alert the on-call DBA has to wake up in the middle of a night when this alert pages us to make sure the host is NOT DOWN. When the monitoring agent tries to ping a node (where index build is running) and fails to communicate with it, it tends to think that the host is down and triggers this alert, although the host is up and running. When an index build is kicked off, it is capture in the mongodb.log. If monitoring agent can check the mongodb.log for an index build or somehow be notified that an index build is running on a node, so NOT to trigger a host is down, that would really help with all the false positive alerts that are being generated.

    Currently, whenever an index build is kicked off on a replica set, it tends to trigger a "host is down" alert. Although this is benign and a false positive alert the on-call DBA has to wake up in the middle of a night when this alert pages us to make sure the host is NOT DOWN. When the monitoring agent tries to ping a node (where index build is running) and fails to communicate with it, it tends to think that the host is down and triggers this alert, although the host is up and running. When an index build… more

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    5 comments  ·  Alerts  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Manage Database Access and Network access

    I would like to give colleagues the ability to manage Database Access and Network access for a project without giving the the project owner role.

    A way to provide more granular access in Atlas would be nice

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  IAM  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Allow threshold on "System Memory: Available" alert condition to be a percentage

    In Atlas, it would be ideal if you could specify a percentage of total memory as the threshold for the "System Memory: Available Is..." rather than a literal number value. If it was possible to set this as a percentage, then the alert could be applied to all hosts in a project, rather than having to set hostname conditions and create a separate alert for each cluster.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. KMIP-based Encryption at Rest

    Problem Statement,
    What is the problem?
    As of now (2021-03-09) Atlas does not support KMIP-based Encryption at Rest. Currently supported (as of 2021-03-09) encryption key sources are,
    * AWS Key Management Service (AWS KMS)
    * Azure Key Vault
    * Google Cloud Key Management Service (Google Cloud KMS).

    Why is this a problem? Customers who use KMIP to source encryption keys are not able to use Encryption at Rest (https://docs.atlas.mongodb.com/security-kms-encryption/) feature of Atlas.

    **Proposal,**
    * Add KMIP support for Encryption at Rest feature of Atlas.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Integrations  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Data Transfer Limit

    since as documented there are limitation on network traffic in M0/M2/M5 instances, it is mandatory to have a metrics/alerts (also for free ones) to monitor this value in a 7d sliding window

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Monitoring and Metrics  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Live Migrate modal: Allow users to point and click to select another Atlas source cluster

    It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

    Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

    It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in the project/organization that could be selected. The required connection parameters could then be automatically populated based on the particular cluster. A temporary user with the required permissions could even be created and then removed after the migration is complete.

    This could make it easier to start Live Migrations between Atlas clusters, and avoid the need for the user to locate and confirm specific source connection requirements.

    It is often practical to Live Migrate from one Atlas cluster to another Atlas cluster (e.g. to create another staging environment if backups are not enabled on the source, or migrate a production/staging environment to another dedicated project with minimal downtime).

    Currently, the Live Migrate modal requires connection details from the source cluster, including the hostname of the primary, port, etc. Validation will fail if there are typos/errors in these inputs.

    It would be easier to have a point-and-click option to "Migrate from another Atlas cluster" -- it could be a drop-down menu with names of other Atlas clusters in… more

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close