1334 results found

1. Select exclusive copy snapshot from different region to restore for testing DR from copy snapshot.

   We have "Additional backup policy" feature enabled which will copy our snapshot to other region.As part of DR testing we want to exlusively select copy snapshot in other region to restore to perform DR.In the current cluster I don't see an option specifically to select snapshot from other region.

   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

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

2. Remove the requirement to have an API Access List CIDR before being able to manage backup schedules

   The issue is described in this github issue, specifically in the linked comment: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/222#issuecomment-855905952

   Here is the requirement as described in the API docs: Remove All Cloud Backup Schedules
   Removes all cloud backup schedules for the specified cluster. "This schedule defines when MongoDB Cloud takes scheduled snapshots and how long it stores those snapshots. To use this resource, the requesting API Key must have the Project Atlas Admin role and an entry for the project access list."
   https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Cloud-Backups/operation/deleteAllBackupSchedules

   Our request is that the requirement to have an API Access List to manage backup policies be removed.

   At the very least, it would be good to document why this restriction is in place so folks like me hopefully stop pestering you about it.

   We understand there is a workaround (adding 0.0.0.0/1 and 128.0.0.0/1 CIDR), but that feels very awkward and is unintuitive.

   The behavior just doesn't match the rest of the API and is very unexpected.

   It sounds like the ship has sailed on this one given the discussion in the github issue, and that's actually ok. But an explanation as to why this requirement is in place would be helpful.

   I suspect this has something to do with the Backup Compliance Policy, but stating that would be very appreciated

   The issue is described in this github issue, specifically in the linked comment: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/222#issuecomment-855905952

   Here is the requirement as described in the API docs: Remove All Cloud Backup Schedules
   Removes all cloud backup schedules for the specified cluster. "This schedule defines when MongoDB Cloud takes scheduled snapshots and how long it stores those snapshots. To use this resource, the requesting API Key must have the Project Atlas Admin role and an entry for the project access list."
   https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Cloud-Backups/operation/deleteAllBackupSchedules

   Our request is that the requirement to have an API Access List to manage backup policies be removed.

   At the very least,… more

   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

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

3. API to list clusters that has snapshots on it- even deleted clusters

   Today we use the API below to list the clusters that exists in a project

   https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Clusters/operation/listLegacyClusters

   GET https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/clusters?pretty=true

   After having the clusters list, we can list the snapshots from one specific clusters using the API:

   https://www.mongodb.com/docs/atlas/reference/api/cloud-backup/backup/get-all-backups/

   GET https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/clusters/{CLUSTER-NAME}/backup/snapshots

   Now on Mongo Atlas I can delete a cluster and ask not to delete their snapshots. So if I want to use the same functions I can't, because the list of the clusters do not show the clusters that have been deleted but still has snapshots on atlas.

   It would be great if the API that lists the cluster also give us those clusters that have been deleted (at list the ones that still has backups on Atlas).

   We use these APIs to be able to migrate our snapshots for a Google cloud storage. So not having this option for the clusters that have been deleted causes problems if we need to migrate snapshots from old clusters.

   Today we use the API below to list the clusters that exists in a project

   https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Clusters/operation/listLegacyClusters

   GET https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/clusters?pretty=true

   After having the clusters list, we can list the snapshots from one specific clusters using the API:

   https://www.mongodb.com/docs/atlas/reference/api/cloud-backup/backup/get-all-backups/

   GET https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/clusters/{CLUSTER-NAME}/backup/snapshots

   Now on Mongo Atlas I can delete a cluster and ask not to delete their snapshots. So if I want to use the same functions I can't, because the list of the clusters do not show the clusters that have been deleted but still has snapshots on atlas.

   It would be great if the API that lists the cluster also give us… more

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

4. Restore protection similar to termination protection

   A restore protection option similar to the termination protection for clusters.
   When a cluster has restore protection enabled, it can't be the target cluster for a restore operation. This will prevent accidental restores to the wrong target cluster from affecting the protected cluster.

   The motivation is preventing mishaps from affecting critical production clusters.
   The UI for selecting the target cluster of a restore operation has you select the cluster from a dropdown and then type in "I Agree". That still leaves you open to mistakenly select the wrong cluster if you aren't paying good enough attention.
   The restore protection feature will prevent you from overwriting your protected clusters in this case.

   A restore protection option similar to the termination protection for clusters.
   When a cluster has restore protection enabled, it can't be the target cluster for a restore operation. This will prevent accidental restores to the wrong target cluster from affecting the protected cluster.

   The motivation is preventing mishaps from affecting critical production clusters.
   The UI for selecting the target cluster of a restore operation has you select the cluster from a dropdown and then type in "I Agree". That still leaves you open to mistakenly select the wrong cluster if you aren't paying good enough attention.
   The restore protection feature… more

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

5. Provide option to remove hidden node in NVMe clusters

   NVMe clusters default to add a hidden node where backups are pulled from. This is due to the reduced durability of NVMe volumes. In cases where durability isn't a concern, I would like to disable backups and remove the hidden node altogether.

   The UI currently provides the ability to stop backups by modifying the backup policies (see attachment). However, I cannot remove the hidden node which is simply incurring extra cost.

   Obviously there would need to be a major warning provided to the user, but this is not unprecedented in industry. AWS has spot instances that are quite successful.

   My use case involves pulling data from Kafka, making it queryable, and storing it for a short period of time (TTL indexed). It's not the end of the world if this data goes away because the nature of the data is such that useful data will come again.

   NVMe clusters default to add a hidden node where backups are pulled from. This is due to the reduced durability of NVMe volumes. In cases where durability isn't a concern, I would like to disable backups and remove the hidden node altogether.

   The UI currently provides the ability to stop backups by modifying the backup policies (see attachment). However, I cannot remove the hidden node which is simply incurring extra cost.

   Obviously there would need to be a major warning provided to the user, but this is not unprecedented in industry. AWS has spot instances that are quite successful.

   My… more

   •  

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

6. disabling snapshots

   When we disable de snapshot from one cluster, the following message is shown in the same page but it does not appear at the page that shows the changes that are being made

   It would be better if this message were also at the second page (as image uploaded)

   Please Note: This action is irreversible. Turning off or altering your type of backup will delete all of your existing snapshots immediately. If you want to keep old versions of your data, visit the backup dashboard and download your snapshots

   •  

   •  

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

7. Suggestion to make the Organization Role Mappings page easier to navigate to

   Make Organization Role Mappings page in the Federation Management App quicker to navigate to. Currently the quickest way is to click the "Create Role Mapping" from the Overview page under "Optional: Set Up Advanced Settings" and then click Cancel.

   If the "Optional: Set Up Advanced Settings" box is not longer available in the Overview page, you'll have to click the Organization tab from the side navigation bar > [Organization Name] > Create Role Mapping > Cancel in order to reach the Organization Role Mappings page.

   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  ·  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. Export profiler slow queries via Datadog integration

   The "profiler" tab in Atlas is very nice -- it gives a really nice over-all view of slow queries, with the ability to drill down into the individual calls.

   However, I don't check this page every day, and so it is sometimes hard to find out when we actually do have slow queries or commands pop up on it if it is not affecting our cluster.

   We use datadog as the central point for all of our monitoring. We have the Atlas <--> Datadog integration set up, which exports a number of useful stats. It would be very nice for the profiler results to be auto-exported to datadog via the integration, because then we could:
   - configure datadog to keep them for as long as we want
   - configure alerts and/or dashboards on this data as we see fit

   I do know that one work-around for this is to manually wire up something to query the profiler REST endpoints and push that to datadog. This is likely what I will end up doing now, but it would make things a lot easier if I (and all other customers using this integration) got this data in datadog "for free" (free in terms of effort).

   The "profiler" tab in Atlas is very nice -- it gives a really nice over-all view of slow queries, with the ability to drill down into the individual calls.

   However, I don't check this page every day, and so it is sometimes hard to find out when we actually do have slow queries or commands pop up on it if it is not affecting our cluster.

   We use datadog as the central point for all of our monitoring. We have the Atlas <--> Datadog integration set up, which exports a number of useful stats. It would be very nice for… more

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

9. AWS ME Central Region Support

   I have an ECS cluster in AWS me-central-1 region and I am not able to establish a peering connection with my AWS VPC as me-central-1 region is missing in the options. When will this option be available?

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

10. Option to Enforce Certain MFA Methods

    Allow certain MFA methods to be disabled for our Organization.
    e.g. we don't trust SMS or Email so want to force our users to only use Google Auth / Security Key/Biomeytric or Okta.

    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

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

11. MongoDB Connection Pool Proxy

    Currently there is no Connection Pool proxy supported by MongoDB.

    With the ever increasing use of serverless and containers, clusters will need to be over provisioned in order to account for the increased connection counts.

    A better solution would be a Connection Pool proxy allowing for a many-to-one relation for connections to MongoDB.

    In the case of Lambda, this would reduce the number of Zombie connections (Connections that have been terminated on the Lambda side but are still open on the server side.)

    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

    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. Option to deploy the databases with pinned version.

    Atlas by default picks the latest patch when we create the databases for any major version. It would be helpful if the customers can choose and control the minor version of the databases(including patch version) when we deploy the cluster. For example: We want to deploy the databases with 4.2.19 but the Atlas is automatically creating 4.2.22

    This will help us identify any application dependencies on any particular patch version during our migration to Atlas, also this will help us test the patch versions in dev/lower environments before we promote the version to production.

    This feature is important for us to identify any application dependencies and avoid any hiccups in production.

    Atlas by default picks the latest patch when we create the databases for any major version. It would be helpful if the customers can choose and control the minor version of the databases(including patch version) when we deploy the cluster. For example: We want to deploy the databases with 4.2.19 but the Atlas is automatically creating 4.2.22

    This will help us identify any application dependencies on any particular patch version during our migration to Atlas, also this will help us test the patch versions in dev/lower environments before we promote the version to production.

    This feature is important for us… more

    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

    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

13. Display Total Cluster Data Size in Atlas UI

    Atlas doesn't display the total data size of the databases hosted on the sharded cluster. This feature was available in Opsmanager and will be very helpful for the DBA's and the product development teams to glance at the data size of the cluster.

    Attached the screenshot for example.

    Nice to have or display the size of each database and also display the historical datasize metric for each database in a sharded cluster.

    •  

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

14. Atlas shards with different clusters tiers

    For solutions of hot and cold storage, there is at least 2 options:
    - Online archiving
    - Hot and cold cluster (using a trigger and datalake)
    But these solutions have limitations (https://www.mongodb.com/docs/datalake/limitations/)

    There is another solution: using sharding.
    We can set shards like so:
    1 shard: Data from the last 2 months -> Hot data
    1 shard: Data between 2 and 24 months -> Warm data
    1 shard: Data more than 24 months -> Cold data

    The usage pattern: 95% of the accesses/queries go to shard with the hot data.
    On Atlas, we need to set the same Cluster Tier in all the shards.
    But in this scenario, the shards with warm and cold data, doesn't need as much CPU and RAM as the other, but it needs more storage.

    So, it would be good to have the availability to set custom cluster tiers for different shards.

    Something like:
    Hot data shard: M60 with 128GB
    Warm data shard: M40 with 256GB
    Cold data shad: M30 with 512GB

    For solutions of hot and cold storage, there is at least 2 options:
    - Online archiving
    - Hot and cold cluster (using a trigger and datalake)
    But these solutions have limitations (https://www.mongodb.com/docs/datalake/limitations/)

    There is another solution: using sharding.
    We can set shards like so:
    1 shard: Data from the last 2 months -> Hot data
    1 shard: Data between 2 and 24 months -> Warm data
    1 shard: Data more than 24 months -> Cold data

    The usage pattern: 95% of the accesses/queries go to shard with the hot data.
    On Atlas, we need to set the same… more

    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  ·  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. increasing the data retention of slow queries to a week.

    Currently atlas storing only 24 hours data for slow queries in Profiler. If it enable for a week atleast it will be very helpful for users to track the slow queries in the last week by sorting the query execution time.

    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

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

16. Test maintenance effects

    While Atlas provides the 'test failover' feature, this only takes effect on the primary of each shard. Customers who run large sharded clusters on Atlas require testing the effects of a full maintenance patch that would restart all mongod's and mongos's, config servers, etc. This feature is a request to improve the chaos engineering features of Atlas.

    At present, customers are being advised to change the TLS version of the cluster which could force restarts of all mongod's, mongos's and config servers. While this may be acceptable in non-production environments, it is unlikely in production environments.

    I believe there's an internal ticket for this already:
    https://jira.mongodb.org/browse/PRODTRIAGE-3411

    While Atlas provides the 'test failover' feature, this only takes effect on the primary of each shard. Customers who run large sharded clusters on Atlas require testing the effects of a full maintenance patch that would restart all mongod's and mongos's, config servers, etc. This feature is a request to improve the chaos engineering features of Atlas.

    At present, customers are being advised to change the TLS version of the cluster which could force restarts of all mongod's, mongos's and config servers. While this may be acceptable in non-production environments, it is unlikely in production environments.

    I believe there's an… more

    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  ·  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. WriteOnly DATA API

    Hello,

    We have a similar need as the one in ticket 44935186, but we would like a WriteOnly (no delete nor read) access to the API so a partner could push data in a collection without being able to read it

    Thx and have a nice day!

    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  ·  Data API  ·  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. Copy/move snapshots from a source to a target cluster

    It is recommended that restoring a cluster must either:
    1) Restore to a new Atlas cluster and reconfigure your application to use that new cluster once the new deployment is running, or,
    2) Ensure that the target Atlas cluster cannot receive client requests while you restore data.
    (src https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore/#prerequisites)

    While doing a PIT restore with the source and target cluster being the same, our clusters have gone into a "down" state 3 times due to obscure errors, opslog not being large enough, or writes happening to the cluster during restore.

    We would like to take the safer route of always restoring to a new cluster.

    However, in doing so we lose the Atlas snapshots and possibly opslog data.

    Feature ask: Ability to copy or move snapshots from a source cluster to a target cluster. This operation would take place after the primary restore completes, if needed.

    A similar feature was asked here, but not exactly the same thing: https://feedback.mongodb.com/forums/924145-atlas/suggestions/44074839-restore-snapshots-on-s3-back-to-atlas-cluster

    It is recommended that restoring a cluster must either:
    1) Restore to a new Atlas cluster and reconfigure your application to use that new cluster once the new deployment is running, or,
    2) Ensure that the target Atlas cluster cannot receive client requests while you restore data.
    (src https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore/#prerequisites)

    While doing a PIT restore with the source and target cluster being the same, our clusters have gone into a "down" state 3 times due to obscure errors, opslog not being large enough, or writes happening to the cluster during restore.

    We would like to take the safer route of… more

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

19. AWS CMK rotation alert should be changed from 90 to 365 days

    Originates from https://github.com/mongodb/terraform-provider-mongodbatlas/issues/805#issuecomment-1241569555

    Short: The created default alert for encryption key rotation is configured to 90 days, also when using AWS KMS CMK. The automatic rotation for CMK is 365 on AWS side. So, I would vote for creating the default alert with 365 days, when AWS KMS CMK is selected.

    Otherwise we get false alerts, as we rely on the automatic rotation of AWS KMS.

    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  ·  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. Metric on TTLDeleted documents

    Hi,
    We (Indeed, inc.) are one of your larger customers with more than $2M spend on Atlas in a year. We need a metric on number of TTL Deleted documents per second for an Atlas Cluster. We have similar metric on our standard mongodb plugin in Datadog and this is extremely useful to all our Product Teams because most of our clusters have TTL.
    Thanks.

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