We want option to export Atlas activity feed in a file to export and work with it. Parse it etc ...

Even better, make a collection with it.

The NewRelic integration in MongoDB is using the default NewRelic API that is in non-EU region. There is a separate API endpoint for EU region, that is described at https://docs.newrelic.com/docs/using-new-relic/welcome-new-relic/get-started/introduction-eu-region-data-center#.

This is causing 'newRelicLicenseKey' failed to authenticate error for the MongoDB Atlas cluster setup in EU region.

Please provide feature to create a dashboard for metrics like CPU, memory consumption etc for a cluster or more than one cluster in single graphs like for cpu one graph, for memory one graph like that just like monitoring tools provide for example zabbix screens and dashboards, stackdriver dashboards, dynatrace dashboards.

This is to have a glance on our entire architecture instead of checking each and every cluster every time. This will be particularly useful during load tests or business peak period where we need to check more than one cluster performance.

This is a request to separate Atlas metric graphs of the outgoing traffic from the internal/replication traffic in Atlas cluster

The Disk IOPS graph shows 2 colored lines. (read/write). It would be great to add a third line which is the SUM of the 2 lines. Or... a toggle switch so we can see the sum line instead of the 2 components. Thanks!

Have an integration with AWS Cloudwatch to send the metrics from MongoDB Clusters to Cloudwatch so metrics and alarms can be setup in CW.

Hi MongoDB Atlas Team,

Some of enterprise customers are left out with improper monitoring via Webhook to ServiceNow (an ITSM tool). Can you please improve on it so right set of fields can be included like "Priority", "Service", "Assignment Group" etc. other details which can be filled up via dropdown or entered manually so alerts to generate incidents via ServiceNow.

Regards,
Varun
Toyota Europe Database Team

The Profiler shows slow query statistics grouped by namespace, but it would also be helpful to view query records grouped by query pattern (perhaps similar to the "pattern" group option in mplotqueries: http://blog.rueckstiess.com/mtools/mplotqueries.html#group-by) and/or by specific fields used in the query.

This could be helpful, for example, for identifying particular query shapes that are executing slowly or suboptimally so that these can be investigated in more detail.

When a shared cluster has reached it's limit and the cluster is throttled, an email should be sent to each db-owner affected. This would save your customers AND your support a lot of time troubleshooting.

Right now there is no way for a db-owner to see this information, let alone get that information, except for asking support for help.

It would be awesome to have possibility to tag alerts in atlas when creating using API or console. It will allow to process groups by alerts by tags without keeping track of ids.
requires:
adding tag field to API create call
adding query by tag to API delete or update calls.

Pavel

Unless I've missed a button somewhere, it would be nice if the "Metrics" tab for clusters and "Status" tab for shards had an option for expanding the entire tiled graph view into a full screen view. We have some TVs around our dev pod where we display these graphs and it would be great to see several graphs at once in full screen view.

Currently Atlas comes with pre-defined Replica set tags such as Provider, Node Types, Region.. But as of now no options for user-defined tags.
Please provide options for custom/user-defined replica set tags.

Allow to replace / restart the underlying virtual machine of a node.

Sometimes this is all that is needed to get a cluster out of an unhealthy state. Currently, only support seem to be able to do this.

When there's an election and the primary changes, it's hard to get a good view on how does the primary functions in a macro fashion.
Please add a monitoring column (or an equivalent solution) that can show the monitoring information for the primary at the time, so I could look at the past month or so, and see how does the primary performed, even if it was a different server every time.

This will make it much easier to understand various actions we take like changing indexes, improving queries, upgrading the database version, upgrading the driver, etc.

There is no good monitoring or alert functionality for dealing with potential invalid login attempts.

I suggest an alert setup to handle events when known users fail more than 3 times to login (either in Atlas or via driverlogin to db).

We have had an external audit done and this is something they have found as a shortage in the MongoDB Atlas environment.

Log files are good but not to monitor potential security issues

It would be amazingly helpful to see more detailed information on recovering nodes. Just knowing that the node is, for example, "81% of the way on initial sync" is much more informational (and lets users know that it isn't stuck) as compared to the node being in "Startup2" recovery.

Right now the 1- and 5-minute metric data is lost after 48 hours (when it is combined into the hourly data). This makes it impossible to take a close look, on a weekday, at an event that occurred over the weekend.

It would be nice to be able to look at a problem on the weekend and say "I'll look at this more closely on Monday", and then have the ability to actually investigate it on Monday.

Like with other type of alert targets (Send to), we would like to be able to resend an alert to PagerDuty.

The reason is that an alert sent to PagerDuty can be mistakenly resolved but the real issue is still there, and the alert is still firing in Atlas.

Because it is already firing, it won't fire again so from that moment on, there is no way to get a notification of that alert so we might be missing a real issue.

If a user submits a configuration change to drop a shard, Atlas will sift through the cluster metrics and advise any necessary changes needed in order to complete the change without any errors/delays. For example, it will share the correct number of IOPS/cluster tier that needs to be used since the workload to drain a shard will increase; as well as other precautionary measures that should happen prior to dropping the shard (i.e. balancer needs to be turned on, etc).