1258 results found

1. Propagation of NodeType via Prometheus metrics

   Context: we rely on Prometheus metrics for various systems in the company. The setup of clusters until now was pretty standard, so basically we had replica sets and sharded clusters with electable nodes only – clusters with three nodes per RS or shard which numbers correspond to <clustername>-<shardnumber>-<(00|01|02)>>. Now we have a fourth analytics node in the clusters, which out of convention seems to get the next incremented number 03.

   The thing is we cannot rely on convention and we need to have a way to distinguish the node types from Prometheus metrics (or at least from the Atlas API) to be able to separate how we react to metrics from different nodes. E.g. we have to react differently for production nodes (electable) than we have to in case of an analytics node.

   I am aware of the tags for node types but I was neither able to see those tags exposed as a label in Prometheus metrics for a specific node nor was it possible to get this from the Atlas API.

   Basically we need to be able to filter Prometheus metrics simplified like e.g. this: mongodbwhatevermetric{clname="<name>", nodetype="electable"}.

   Context: we rely on Prometheus metrics for various systems in the company. The setup of clusters until now was pretty standard, so basically we had replica sets and sharded clusters with electable nodes only – clusters with three nodes per RS or shard which numbers correspond to <clustername>-<shardnumber>-<(00|01|02)>>. Now we have a fourth analytics node in the clusters, which out of convention seems to get the next incremented number 03.

   The thing is we cannot rely on convention and we need to have a way to distinguish the node types from Prometheus metrics (or at least from the Atlas API)… more

   26 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

2. Integrar la alerta de Replication lag de Atlas en el API de Prometheus

   Se solicita incluir métricas en el API de prometheus para poder implementar la alarma de Replication lag

   6 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

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

4. Request for Enabling Vendor-Metered Tagging on AWS Marketplace

   Hi Team,

   We are currently utilizing MongoDB services via the AWS Marketplace and have encountered an issue related to cost allocation tags.

   We have recently been working on improving our cost management and reporting processes within AWS.
   A key component of this effort involves leveraging AWS-generated cost allocation tags, particularly those prefixed with "aws:marketplace:isv:".
   However, upon review, we have noticed that these specific tags are not available or being applied to MongoDB services that we are using.

   The absence of vendor-metered tags for MongoDB on AWS Marketplace is hindering our ability to effectively track and allocate costs associated with your services. This capability is crucial for our organization’s internal cost management and reporting.

   Therefore, we kindly request your assistance in enabling support for vendor-metered tagging for MongoDB services on AWS Marketplace. Implementing this feature would greatly assist us in managing our AWS expenses more efficiently and accurately.

   Hi Team,

   We are currently utilizing MongoDB services via the AWS Marketplace and have encountered an issue related to cost allocation tags.

   We have recently been working on improving our cost management and reporting processes within AWS.
   A key component of this effort involves leveraging AWS-generated cost allocation tags, particularly those prefixed with "aws:marketplace:isv:".
   However, upon review, we have noticed that these specific tags are not available or being applied to MongoDB services that we are using.

   The absence of vendor-metered tags for MongoDB on AWS Marketplace is hindering our ability to effectively track and allocate costs associated with your… more

   8 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  ·  Billing  ·  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. Programatically disable/enable Auto indexing Serverless

   We have Serverless instances. We want to be able to programmatically (using atlas api and terraform resource) disable/enable
   mongo atlas to auto create suggested indexes for given mongo Serverless instance. Currently, it is enabled by default and can be disabled only by toggle in Mongo UI.

   With programmatically way we can easily disable/enable auto indexing on all our Serverless instances.

   This is important to us because we want to use only indexes that we create.

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

6. Altas CIDR ranges for network containers are too restrictive

   Background:
   For each MongoDB Altas project, the clusters built in that project are built using a "network container", which tells MongoDB Atlas which pool of IPs it can select from given a CIDR range for its underlying infrastructure.

   AWS minimum imposed CIDR value/subnet size: /28
   MongoDB minimum imposed CIDR value for clusters deployed to AWS: /24

   Azure minimum imposed CIDR value/subnet size: /29
   MongoDB minimum imposed CIDR value for clusters deployed to Azure: /21

   For customers who elect connecting to MongoDB Atlas via VPC peering, they know that IP space is a scarce resource. Reserving /24 or /21 IP space from IPAM does not scale when your project footprint in MongoDB Atlas grows sufficiently large.

   Attempting to combine projects into a single cohesive project for utilizing the larger IP space (as MongoDB likely intended) does not scale either. There is a soft cap on the amount of clusters which can be deployed to a project (25). The cap can be raised but concerns with monitoring, backups, and visibility into all clusters in the project becomes a concern, as well as further complicating billing and RBAC management in larger orgs.

   For customers with smaller deployments, like simple 3 node replica sets in AWS, MongoDB asking us to allocate a bare minimum of /24 (255 IPs) when only 3 IPs are needed, thats a ton of overhead on IPAM that goes to waste unnecessarily. The problem is even more exaggerated for 3 node replica sets in Azure, where the bare minimum network container size Atlas is /21 resulting in over 2000+ IPs going to waste.

   Proposed solution:
   MongoDB raise the minimum required network container size to /28 for all projects.

   Thank you

   Background:
   For each MongoDB Altas project, the clusters built in that project are built using a "network container", which tells MongoDB Atlas which pool of IPs it can select from given a CIDR range for its underlying infrastructure.

   AWS minimum imposed CIDR value/subnet size: /28
   MongoDB minimum imposed CIDR value for clusters deployed to AWS: /24

   Azure minimum imposed CIDR value/subnet size: /29
   MongoDB minimum imposed CIDR value for clusters deployed to Azure: /21

   For customers who elect connecting to MongoDB Atlas via VPC peering, they know that IP space is a scarce resource. Reserving /24 or /21 IP space… more

   5 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

7. Alert for the absence of a snapshot backup policy

   It would be great to have an alert option that notifies when there is a cluster configured without a backup policy defined.

   This alert option would be helpful to ensure any defined company backup policy is audited and we are notified if a policy does not exist, or if someone accidently removes any defined policies on a give production cluster.

   5 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  ·  Backup  ·  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. SIEM

   Add audit log integration with enterprise SIEMs

   6 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  ·  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. View billing information at project level

   I think it would be a good idea to be able to see billing/invoices at project level. So the project owner will only see the consumption of his projects.

   By giving project owners the "Organization Billing Viewer" role, we make it possible for them to see the billing for the whole organization. A new role for the project owner to view only their own project invoices would be nice.

   5 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  ·  Billing  ·  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. Support Online Archive in Azure Switzerland North region

    Please make Online Archive available in Azure's Switzerland North region

    We are using MongoDB Atlas in Azure notably to store personal health data of patients. We are based in Switzerland (which is not part of the EU), and the regulation requires that health data remains in Switzerland. We would like to use the Online Archive on Azure feature for our Atlas data but require that it is available in the Switzerland North region.

    4 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

11. Ability to schedule "Hedged read" Turn on/off

    Customer experienced read latency during maintenance after sharding.
    Our guidance is to turn on "Hedged read" option.
    So the customer need to turn on/off "Hedged read" before/after maintenance, because turning on "hedged read" increase CPU usage that means server cost increasing.

    Currently "hedged read" on/off can be done by technical support from MongoDB but this feature is needed for operational efficiency and reducing human error.

    8 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

12. Terraform lifecycle ignore_changes tags

    It would be nice if tags would not be set of list and will be a map, like tags for Azure resources.
    In that case, you can ignore some tags by name. Like this

    lifecycle {
    ignore_changes = [
    tags["costcenter"],
    tags["environment"],
    tags["projectcode"]
    ]
    }

    https://github.com/mongodb/terraform-provider-mongodbatlas/issues/2006

    3 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  ·  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. "Manage your own encryption keys deactivated" event

    We recently discovered that there is no event when deactivating the option "Manage your own encryption keys" within the cluster configuration.

    While there are hints towards this within the CLUSTERUPDATESTARTED and AUTOMATIONCONFIGPUBLISHED_AUDIT events, there is no clear warning that the encryption keys of the cluster are affected.

    As an unwanted change of encryption at rest keys for data can have severe impact on data accessibility and security, I would propose adding a "Manage your own encryption keys deactivated" event to the Activity Feed.

    3 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  ·  Activity Feed  ·  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. 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

15. Customize CPU threshold for Autoscaling

    Currently, to autoscale a cluster to the next tier, the "Average CPU Utilization must have exceeded 75% of available resources for the past hour."

    Problem:

    Some workloads remain near the 75% CPU threshold, given the nature of the workload. This can cause constant scaling events to occur which creates unnecessary noise.

    We don't want to turn autoscale off because this is a beneficial feature to keep enabled on the cluster.

    Solution:

    We want to be able to configure the CPU % threshold for cluster tier scaling. For example, rather than 75%, we'd like the option to set the threshold to 85 or 90%.

    Currently, to autoscale a cluster to the next tier, the "Average CPU Utilization must have exceeded 75% of available resources for the past hour."

    Problem:

    Some workloads remain near the 75% CPU threshold, given the nature of the workload. This can cause constant scaling events to occur which creates unnecessary noise.

    We don't want to turn autoscale off because this is a beneficial feature to keep enabled on the cluster.

    Solution:

    We want to be able to configure the CPU % threshold for cluster tier scaling. For example, rather than 75%, we'd like the option to set the threshold to… 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

    0 comments  ·  Autoscaling  ·  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. All Clusters permission for ORG level roles

    Today, for you to be able to use All Clusters you need to have permissions on each project, your user needs to be included in each project.

    When we use a federation, we generally don't grant permission for each project to a team of administrators. We grant ORGOWNER, for example. By doing this, we lose access to All Clusters. The idea was to include the permission to use All Clusters for project-level permissions that have permissions to read project resources, for example ORGOWNER or ORGREADONLY.

    6 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

17. Disable Query Targeting alert notifications for $changeStream operations

    Change streams require scanning of the oplog and cannot make use of indexes, meaning that $changeStream operations frequently trigger Query Targeting: Scanned Objects / Returned alerts that cannot be actioned. It would be ideal to allow $changeStream operations to be filtered from the Query Targeting alerts.

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

18. Push Logs to AWS S3 bucket: Terraform

    Push Logs to AWS S3 bucket, This feature is helpful, It gives a flexibility for large organizations who need to segregate logs considering Inventory, Security and Observability to organize logs to a respective destinations from S3.However the terraform provider does have api's to fulfill this feature https://www.mongodb.com/docs/atlas/push-logs/ . If it can available in terms of terraform resources, This will help our organization to enable logging in terraform IAC to simplify the logging and deployments

    3 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  ·  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
    started  ·  AdminZuhair (Admin, MongoDB) responded

    Hi Jai, thanks for sharing feedback. This item is already under development and should be published to Terraform Registry over next few weeks! 

19. Incorporate Resource Tags in Atlas alerts

    Enhance the alert content by incorporating the resource tags of the entity that triggered the alert.

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

20. Add usability to tags

    Atlas has the option to set tags to clusters. But - now what? They are just pieces of text floating around, but are completely useless.
    How about enabling to filter clusters in a project or even organization based on those tags? Split costs based on them? Query them with API calls? I have no use of those tags when they are just texts in the main page of Atlas...

    7 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