1293 results found

1. Activity feed filters - allow filtering by cluster node name

   We need to be able to filter the activity feed based on the name of the cluster's nodes, not just the name of the cluster itself.

   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

   2 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

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

   27 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

3. Performanse advisor node type filter (to exclude analytics)

   Performance Advisor should allow selecting node types to exclude analytics nodes.

   In most cases, analytics queries don't require indexes as queries are very different and might be filtered by any field.

   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  ·  Performance Advisor  ·  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. Manage Database by Kubernetes Operator

   In our use case, we are dynamically creating feature environments based on the branch name. During this process, we are also creating MongoDB databases in the same Atlas cluster (different envs are sharing the same cluster but with different database names). For now, we need to do it with a separate CI step that should create this DB and delete it when the env is deleted.

   It would be great to have the possibility to manage DB create/delete process with Kubernetes CRD. For now it's the only 1 missing feature that is blocking us to start using Operator.

   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

   1 comment  ·  Kubernetes Operator  ·  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
   under review  ·  AdminDan (Admin, MongoDB) responded

   This is something we're considering for the future. 

   
   

   But the biggest problem we need to solve is that it's incredibly easy to create/delete/update databases within a deployment via many other interfaces. But if this happens, the Operator's source of truth (the custom resources) won't contain the changes, and the Operator would overwrite the changes using it's source of truth.

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

   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

6. Atlas Webhook Integration and Custom JSON Payload

   Ability to specify a JSON body along with their Atlas Webhook's for additional functionality.

   •  

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

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

   12 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

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

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

10. Unblock users in Russia and Belarus

    Currently MongoDB blocks access to MongoDB Atlas for users who are located on the territory of Russian Federation, Belarus (and other countries).

    MongoDB Support team confirmed this is the case and stated that the reason is US regulations and sanctions, referring only to the blog post published on their website (https://www.mongodb.com/blog/post/mongodb-assistance-ukraine-shut-down-work-russia). The blog post does not mention that the access to users is blocked.

    To our best understanding not many other tech companies have implemented such strict measures.

    We've also taken the time to delve into the sanctions topic and have reviewed every public release of sanctions on the U.S. Department of State website (Ukraine and Russia Sanctions). Interestingly, we didn't find any information mandating American companies to block users from Russia or Belarus.

    Despite the sanctions, the U.S. Department of the Treasury (Russian Harmful Foreign Activities Sanctions) authorises transactions related to telecommunications and certain internet-based communications (General License 6C). We came to a conclusion that MongoDB is not legally required to block access for users geographically located in Russia or Belarus.

    For our product that is heavily dependant on MongoDB Atlas managed service (including MongoDB Realm) it is crucial to continue to provide access to our clients in Russian Federation and Belarus which make the majority (more than 90%) of our users.

    We also operate as a social Christian business and strongly believe that our efforts are valuable in the light of the ongoing war in Ukraine, particularly in fostering compassion and mercy among the Russian population by providing access to spiritual literature.

    We hope to discuss the possibility to implement of an exception for our project Teleios Bible (https://www.teleios.bible).

    Currently MongoDB blocks access to MongoDB Atlas for users who are located on the territory of Russian Federation, Belarus (and other countries).

    MongoDB Support team confirmed this is the case and stated that the reason is US regulations and sanctions, referring only to the blog post published on their website (https://www.mongodb.com/blog/post/mongodb-assistance-ukraine-shut-down-work-russia). The blog post does not mention that the access to users is blocked.

    To our best understanding not many other tech companies have implemented such strict measures.

    We've also taken the time to delve into the sanctions topic and have reviewed every public release of sanctions on… more

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

12. "Atlas Onboarding"

    Allow user to escape from onboarding without having to edit the url.
    When the system doesn't accept the input, the user cannot escape and see their dashboard.

    1 vote

    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  ·  Tutorials/How-tos  ·  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. Authority Root/Intermediate Certificate from Let's Encrypt update

    Need to be notified when Authority Root/Intermediate Certificate from Let's Encrypt will be upgraded. It can be a alert/rss flow/notification/email to inform the customer company.
    From documentation https://www.mongodb.com/docs/atlas/reference/faq/security/#hard-coded-certificate-authority (Which certificate authority signs MongoDB Atlas TLS certificates?)

    2 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

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

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

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

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

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

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

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

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

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

20. Incorporate Resource Tags in Atlas alerts

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

    12 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