1346 results found

1. Log browser and log search capability across replicaset nodes.

   Currently to search through logs we have to download them and search through each log. It would be helpful to have a log browser capability that would allow us to look through and search all logs from the Atlas portal interface.

   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  ·  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

2. Using Online Archive with Customer Encryption Keys

   I'd like to use Online Archive but I need to use Encryption Keys that my company manages, not ones provided by MongoDB.

   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  ·  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

3. 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

4. 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

5. 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

6. 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

7. 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

8. Support for push-based logging integration with Google Cloud Storage

   As of now, MongoDB Atlas supports log export functionality exclusively with AWS S3. In addition to the existing AWS S3 bucket integration, would be good to have the capability of pushing logs to GCP Cloud Storage for organisations who depend on GCP for cloud infrastructure.

   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  ·  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

9. 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

10. 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

11. 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

12. 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

13. 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

14. Implement AWS transit gateway support

    VPC peering and Private Endpoints have limitations that make them unusable in some environments. Implementing native transit gateway support would allow admins with hybrid infrastructures and strict security requirements to control routing and security at a lower level then is currently supported.

    VPC peers do not support pass through routing, so organizations that use transit gateways to attach IPSEC tunnels or other external networks to AWS are unable to access atlas servers via these peer connections.

    Private Endpoints do allow connectivity in these cases, but cause an additional layer of expense, complexity, and reduced security. First, the "user" side still needs an underlying transit gateway network to route between networks without peering capability adding to cost and complexity. But the VPC endpoints don't listen on fixed ports, so security admins are unable to lock the service down based on service port.

    In the second case, simply adding transit gateways to the Atlas VPCs would eliminate the cost and additional complexity of the private endpoints. Improve throughput as traffic wouldn't be routed through the endpoint abstraction layer. And maintain direct access to port 27017 on the servers so that security can limit access and closely monitor open ports.

    VPC peering and Private Endpoints have limitations that make them unusable in some environments. Implementing native transit gateway support would allow admins with hybrid infrastructures and strict security requirements to control routing and security at a lower level then is currently supported.

    VPC peers do not support pass through routing, so organizations that use transit gateways to attach IPSEC tunnels or other external networks to AWS are unable to access atlas servers via these peer connections.

    Private Endpoints do allow connectivity in these cases, but cause an additional layer of expense, complexity, and reduced security. First, the "user" side still… 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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