Monitoring, Alerting, and Performance Tuning
This domain tests how you observe Atlas health, configure alerts, and use Atlas tooling to find and fix slow queries.
Core rules
- Atlas metrics cover CPU, memory, disk utilization and IOPS, connections, opcounters, replication lag, cache, and query targeting. Watch scan-and-order ratio and keys-examined-to-documents-returned.
- Alerts are configured at project level. Atlas has default alerts and custom alerts; route notifications to email, SMS, Slack, PagerDuty, webhooks, or integrations. Alert conditions can be edited or muted, but muting hides real incidents.
- Performance Advisor analyzes slow-query logs and recommends indexes; it requires a dedicated cluster and does not apply indexes automatically. Query Profiler shows sampled slow operations; the Real-Time Performance Panel shows current activity.
- Use explain with executionStats, db.currentOp(), and $indexStats to confirm index use before creating new indexes.
- Replication lag can come from network issues, long-running operations, write bursts, or undersized secondaries.
Worked example
A checkout query slows after a release. Atlas shows high CPU and a query targeting ratio near 500. Performance Advisor suggests an index on status and createdAt. Explain shows a COLLSCAN and an in-memory sort. Create the compound index in the suggested order, verify the plan uses an index scan and no blocking sort, then confirm CPU and latency recover. Do not create every suggested index at once; each adds write cost.
Traps
Treating Performance Advisor as automatic tuning; ignoring write amplification from too many indexes; setting alerts but never testing notifications; assuming a high cache hit ratio means queries are efficient; missing replication lag from an undersized secondary.