It would be good to see Log Redaction work in Atlas as well, similar to On Prem
https://docs.mongodb.com/manual/administration/monitoring/#log-redaction

Add process measurements for monitoring WiredTiger data handles.

From Atlas documentation https://docs.atlas.mongodb.com/reference/atlas-limits/#collection-and-index-limits :
> While there is no hard limit on the number of collections in a single cluster, the performance of a cluster might degrade if it serves a large number of collections and indexes. Larger collections have a greater impact on performance.

but now there is no way to get this information except db.serverStatus()

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.

We have set up alerts and have noticed that when a condition is back to normal, there is another alert generated acknowledging its closed. Is there a way we can manage this (like disable or block it for some alerts)?

It would be useful, and contribute to a complete alert experience, to have auto-scaling event alerts configurable in project alerts. Users should be able to send alerts to their target system of choice, and prevent numerous alerts to specific users.

Currently auto-scaling alerts are only emails to project members (as per the following https://docs.atlas.mongodb.com/cluster-autoscaling/#acknowledge-auto-scaling-events).

Examples of configurable alerts:
- Scale-up unsuccessful due to max cluster-tier too low -> change email recipient of these alerts
- Scale-up event has occurred -> send alert via SMS and Slack.

Implement better monitoring and alerting for WT dirty cache ratio. This should include sub-minute resolution and support an understanding of eviction workload as well as performance impact of checkpoints under heavy write workloads.

I would like to be able to track the size of our collections (i.e. # of records, total disk size) over time. It would be ideal if there was an automated way to do this with Atlas, perhaps with Charts ?

We have configured several alerts and are having them emailed to us. The subject line of the email alert is something like "[External]Alert - <CLUSTER NAME> - 2021-04-08T12:26Z". We would like the subject line to show what exactly is the alert for - for example - if the alert is for "System Memory: Available has gone below 3.2 GB", we would like the subject to include this information. All the email alerts have the same subject line except for the change in time. Please consider this request. Thank you.

Currently closed alerts are just a simple text card unlike open alert which does have links. This functionality should be available in closed alert as well.

Monitoring Integration with Azure Event Grid.

Would be nice to export the database access history and/or sort by a column.

Any way could analyze and store all the queries we have made
Fields would be: execution time, IO, cpu usage, etc...
This collection would store only 1 or 2 months of data.

Customer is requesting that an alert be sent out if project IP access list gets changed

The profile page would be more use if the listing included the username so you could work out which application was making the queries.

on MongoAtlas metrics dashboard, I can organize graphically different metrics as I want to display first "insert" metric for example, then "cpu" metric, etc ...
If I change this actual order, then I go to another screen (for example "network access") and finally I come back to this metric dashboard, my new metrics added (insert, cpu, ...) in first position are not in wanted first position (at the top of metrics list), but at the end of this metrics list.

It would be great to keep metrics context (displayed metrics and ordering) on Metrics dashboard.

It would be ideal if the alert notifications for Query Targeting ratio alerts included a reference to the query shape that caused the alert to fire. This would assist customers in locating the exact query/queries with poor targeting ratios so that they can be optimized in a more expeditious manner.