AdminAndrew Davidson
(VP, Cloud Products, MongoDB)
My feedback
-
1 vote
An error occurred while saving the comment -
1 vote
An error occurred while saving the comment Hi Steven,
The first-order cost contributor to an Atlas cluster is its compute (memory and CPU) requirements rather than storage size. Unfortunately larger and larger numbers of connections require more compute. Note that you may be able to optimize with connection pools.
-Andrew
-
1 vote
An error occurred while saving the comment Hi Benjamin,
You can actually do this within the scope of the project's own alert settings (rather than the organization scoped alerting).
-Andrew
-
1 vote
An error occurred while saving the comment Hi Geoffrey,
Definitely a cool concept. I do want to make sure that you're aware that you can pull this data via an API endpoint programmatically https://docs.atlas.mongodb.com/reference/api/events and can from there route the data to a destination of your choice. You could probably do this with a scheduled Trigger powered by MongoDB Realm by the way: https://docs.mongodb.com/realm/triggers/scheduled-triggers
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Geoffrey,
If we made it possible to alert on actions or deployments that meet or exceed certain criteria, would that offer a helpful mitigating control?
Thanks
-Andrew -
1 vote
An error occurred while saving the comment Hi Brian,
Atlas contemplates the use case of being able to return to a point in time differently, through our Cloud Continuous Backups: these allow for up to the minute restores and leverage some of the same primitives that the replication system leverages (namely the internal oplog). This has the added benefit of giving you the ability to select the point of time to restore to rather than a specific delay period.
-Andrew
-
11 votes
An error occurred while saving the comment Hi Nischal,
Can you add some color around the use case: is the reason you're aiming to disable alerts that you're spinning up a non-prod project programmatically and just don't want to be bothered by any alerts? Or rather that you just want a completely separate set of alerts than the default; if the latter do we potentially have the wrong defaults? or is it more that you want to customize destinations (not email) and that kind of thing? Appreciate ay extra perspective here.
Thanks
-Andrew -
1 vote
An error occurred while saving the comment H Geoffrey,
The in-console Project and Organization level Activity Feed (which is also accessible via the Events API endpoint https://docs.atlas.mongodb.com/reference/api/events) is actually retained for much longer than 30 days. At this time it is actually retained forever but we will likely be forced to cap it in future.
For completeness, it's the database process logs and database audit logs which are maintained for 30 days.
Cheers
-Andrew -
2 votes
An error occurred while saving the comment Hi Tomek, Have you seen Atlas Online Archive by chance?
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Vipin,
Note that it's not possible to downgrade after the Feature Compatibility Version has been upgraded, and generally we recommend running a test in a staging environment before upgrading production.
Please reach out proactively to MongoDB support about options.
-Andrew
-
1 vote
An error occurred while saving the comment Hi Aniketh,
Thanks a lot for taking the time to provide this feedback. This is big and exciting feedback. Information architecture for the platform is definitely a tough one and there are tradeoffs to different approaches. We will definitely consider your perspective as we figure out where to go next.
-Andrew
-
1 vote
An error occurred while saving the comment Hi Guillaume, have you thought about using the Atlas Backup/Restore for this use case instead?
Cheers
-Andrew -
2 votes
An error occurred while saving the comment Hi Greg, I realize it's not what you're asking for but I do want to share that many users achieve this objective by managing programmatically via the Atlas API.
We'd love to introduce a more full featured experience for this in future.
-Andrew -
2 votes
An error occurred while saving the comment Hi Katherine,
MongoDB Atlas offers the ability to federate identity to your identity provider today for control plane access, please see https://docs.atlas.mongodb.com/security/federated-authentication/
Cheers
-Andrew -
3 votes
An error occurred while saving the comment Hi Kyle,
Conceptually this is something we would like to introduce in future.
-Andrew
An error occurred while saving the comment Hi Dan,
It's important to emphasize that the only portion of logs that can contain query contents is the slow query logs: MongoDB Atlas provides a lot of high-value capability on top of these slow query logs, ranging from the Performance Advisor which provides index suggestions to the Query Profiler.
Importantly, access to database process logs is limited to Project Data Access Read Only users and above, and accesses of logs are audited events in the Project-level activity feed. You can lock down environments by managing your infrastructure in code, and give Project Read Only (as distinct from Product Data Access Read Only) to most users (this will mean they will have metadata access view only, including monitoring, without access to log files).
Longer-term we plan to move to model that can provide finer grained authorization for users to be granted the right to perform privileged actions on specific resources. We also aspire to provide richer, more configurable views into logs and other diagnostics data.
Also I should point out that MongoDB also offers Client-Side Field Level Encryption which allows you to encrypt data of the highest classification level before it ever leaves your network, with the tradeoff that you give up some queryability on those fields (point queries continue to work, but range queries do not). See more here: https://docs.mongodb.com/drivers/use-cases/client-side-field-level-encryption-guide
-Andrew
-
1 vote
An error occurred while saving the comment Hi John,
One thing to consider is to build an API call into the app-tier failover orchestration layer which changes the preferred region of the Atlas cluster upon failover.
I definitely think the idea of automatically deducing is cool: but there are situations where ti might nevertheless not be intended so getting the exact mechanics right is nontrivial.
-Andrew
-
2 votes
An error occurred while saving the comment Hi Mert, Luke,
I'm sorry I missed this when it was first opened:
It's important to know that Atlas offers configurable workload isolation using *tags*: you can learn more here https://docs.atlas.mongodb.com/reference/replica-set-tags/index.html#node-types
For example you can create Analytics nodes which in turn allow you to isolate analytics (or any other kind of) workloads from operational workloads: you specify the tag in the connection string.
We don't use "hidden" replicas from an implementation perspective since those actually don't work in a sharded setting, and tagging achieves similar objectives.
-Andrew
-
1 vote
An error occurred while saving the comment Hi James,
I'm sorry about this limitation as it currently stands: to explain, we show currentOp information within the RTPP that can show query predicates that in turn can contain sensitive information.
We hope to have a more flexible authorization model in the future because there's definitely a middle ground to be found.
-Andrew
-
2 votes
An error occurred while saving the comment Hi Anthony,
As much as we'd love to be everywhere, it's unfortunately a monumental lift to build out on top of a new provider.
Out of curiosity, are you using a DO region adjacent to any of our supported cloud provider regions? if so I wonder how the latency would be? It'd be great if we could get the magic of DO for the app tier coupled with Atlas for the data tier using existing building blocks.
-Andrew
-
1 vote
An error occurred while saving the comment Hi David,
Unfortunately at the TCP layer we will only see the source IP address of the request and not your domain.
However, please note that MongoDB Atlas requires security in depth including database level authentication on top of the IP Access List (we have already changed the name of this capability in the UI btw).
Selective IP Access List management is a best practice but many customers do open up to 0.0.0.0/0 and take care to ensure their database cluster passwords are securely managed.
Another option is to procure a static IP address or leverage VPC peering.
-Andrew
Hi Klaus,
Can you provide more detail on what you're aiming to use SNMP for and whether you're using SNMP in the public cloud more generally? We've not seen it come up outside the on-prem paradigm and want to make sure we're tracking the technologies customers are using.
What are you looking to use SNMP for: alerting? could you use one of MongoDB Atlas's many other alerting destinations instead?
Thanks
-Andrew