Monitoring with Atlas metrics in MongoDB - Step-by-Step Execution

Concept Flow - Monitoring with Atlas metrics

Enable Atlas Monitoring

↓

Collect Metrics from Cluster

↓

Store Metrics in Atlas

↓

Visualize Metrics on Dashboard

↓

Set Alerts Based on Thresholds

↓

Respond to Alerts or Analyze Trends

This flow shows how Atlas collects, stores, and displays metrics for monitoring your MongoDB cluster, enabling alerting and analysis.

Execution Sample

MongoDB

db.adminCommand({ getFreeMonitoringStatus: 1 })
// Check if monitoring is enabled

// View metrics in Atlas UI dashboard

// Set alert thresholds in Atlas console

This sequence checks monitoring status, then uses Atlas UI to view metrics and configure alerts.

Execution Table

Step	Action	Command/Operation	Result/Output
1	Check monitoring status	db.adminCommand({ getFreeMonitoringStatus: 1 })	{"state": "enabled"}
2	Atlas collects metrics	Automatic background process	Metrics like CPU, memory, ops/sec collected
3	Store metrics	Atlas backend	Metrics stored securely and updated every minute
4	Visualize metrics	Atlas UI dashboard	Graphs show cluster health and performance
5	Set alert	Configure alert for CPU > 80%	Alert rule saved in Atlas
6	Trigger alert	CPU usage spikes above 80%	Alert notification sent to user
7	Respond to alert	User investigates issue	Issue diagnosed and resolved
8	Exit	Monitoring continues	Continuous data collection and alerting

💡 Monitoring runs continuously; this trace shows one alert cycle.

Variable Tracker

Variable	Start	After Step 1	After Step 4	After Step 6	Final
Monitoring Status	unknown	enabled	enabled	enabled	enabled
CPU Usage (%)	N/A	N/A	45	85	70
Alert Triggered	false	false	false	true	false

Key Moments - 3 Insights

Why does the monitoring status need to be checked first?

Checking monitoring status (Step 1) confirms if Atlas is collecting metrics; without it enabled, no data appears on the dashboard.

How does Atlas know when to send an alert?

Atlas compares live metrics against alert thresholds (Step 5). When CPU usage exceeds 80% (Step 6), it triggers an alert notification.

Does monitoring stop after an alert is sent?

No, monitoring runs continuously (Step 8). Alerts notify issues but data collection and visualization keep going.

Visual Quiz - 3 Questions

Look at the execution table, what is the monitoring status after Step 1?

A "unknown"

B "enabled"

C "disabled"

D "pending"

💡 Hint

Check the 'Result/Output' column in Step 1 of the execution table.

At which step does the alert get triggered due to high CPU usage?

A Step 4

B Step 5

C Step 6

D Step 7

💡 Hint

Look for the step mentioning CPU usage spikes above 80% in the execution table.

If the monitoring status was "disabled" at Step 1, what would happen to the metrics collection?

A Metrics would not be collected or displayed

B Metrics would still be collected normally

C Alerts would trigger regardless

D Only CPU metrics would be collected

💡 Hint

Refer to the key moment about why checking monitoring status is important.

Concept Snapshot

Monitoring with Atlas metrics:
- Enable monitoring via db.adminCommand
- Atlas collects and stores cluster metrics
- Metrics shown on Atlas dashboard
- Set alerts for thresholds (e.g., CPU > 80%)
- Alerts notify you to act
- Monitoring runs continuously

Full Transcript

Monitoring with Atlas metrics involves enabling monitoring on your MongoDB cluster, which allows Atlas to collect performance data like CPU usage and operations per second. This data is stored and visualized in the Atlas dashboard, where you can watch your cluster's health. You can set alert rules to notify you when metrics cross thresholds, such as CPU usage exceeding 80%. When an alert triggers, you receive a notification to investigate. Monitoring continues running in the background, collecting data and sending alerts as needed.

Practice

1. What is the main purpose of monitoring MongoDB Atlas metrics?

easy

A. To track database health and performance

B. To write database queries faster

C. To create new database users

D. To backup data manually

Solution

1. Step 1: Understand the role of monitoring

   Monitoring helps watch how well the database is working and if there are any problems.

2. Step 2: Identify the purpose of Atlas metrics

   Atlas metrics provide data about database health and performance to keep it running smoothly.

3. Final Answer:

   To track database health and performance -> Option A

4. Quick Check:

   Monitoring = Track health and performance [OK]

Hint: Monitoring means watching health and speed [OK]

Common Mistakes:

• Confusing monitoring with query writing
• Thinking monitoring creates users
• Assuming monitoring is for manual backups

2. Which of the following is the correct way to access Atlas metrics via the API?

easy

A. GET /api/atlas/v1.0/groups/{GROUP-ID}/processes/{PROCESS-ID}/measurements

B. POST /api/atlas/v1.0/groups/{GROUP-ID}/processes/{PROCESS-ID}/measurements

C. DELETE /api/atlas/v1.0/groups/{GROUP-ID}/processes/{PROCESS-ID}/measurements

D. PUT /api/atlas/v1.0/groups/{GROUP-ID}/processes/{PROCESS-ID}/measurements

Solution

1. Step 1: Identify the HTTP method for fetching data

   To get metrics, we use the GET method because it retrieves information.

2. Step 2: Confirm the API endpoint format

   The endpoint includes group and process IDs and ends with /measurements to fetch metrics.

3. Final Answer:

   GET /api/atlas/v1.0/groups/{GROUP-ID}/processes/{PROCESS-ID}/measurements -> Option A

4. Quick Check:

   GET method fetches data [OK]

Hint: GET method reads data from API [OK]

Common Mistakes:

• Using POST instead of GET to fetch data
• Confusing DELETE or PUT with data retrieval
• Missing required path parameters

3. Given this API call to Atlas metrics:

curl -X GET \
'https://cloud.mongodb.com/api/atlas/v1.0/groups/12345/processes/cluster0-shard-00-00/measurements?granularity=PT1M&metricNames=CPU_USER'

What does the response mainly contain?

medium

A. A list of database users created in the last minute

B. A list of error logs from the last minute

C. A list of backup snapshots taken every minute

D. A list of CPU user usage values sampled every minute

Solution

1. Step 1: Analyze the API parameters

   The metricNames=CPU_USER means it requests CPU usage by user processes.

2. Step 2: Understand granularity=PT1M

   This means data is sampled every 1 minute (PT1M is ISO 8601 duration for 1 minute).

3. Final Answer:

   A list of CPU user usage values sampled every minute -> Option D

4. Quick Check:

   CPU_USER metric with 1-minute samples = CPU usage data [OK]

Hint: metricNames shows what data is returned [OK]

Common Mistakes:

• Thinking it returns user accounts
• Confusing metrics with backups
• Assuming error logs are returned

4. You run this API call but get a 400 Bad Request error:

curl -X GET \
'https://cloud.mongodb.com/api/atlas/v1.0/groups/12345/processes/cluster0-shard-00-00/measurements?granularity=1m&metricNames=CPU_USER'

What is the likely cause?

medium

A. Missing API key in the request headers

B. Incorrect granularity format; should be ISO 8601 duration like PT1M

C. Wrong HTTP method; should be POST instead of GET

D. Invalid process ID format

Solution

1. Step 1: Check the granularity parameter format

   The API expects granularity in ISO 8601 duration format, e.g., PT1M for 1 minute.

2. Step 2: Identify the error cause

   Using '1m' instead of 'PT1M' causes the 400 Bad Request error due to invalid parameter format.

3. Final Answer:

   Incorrect granularity format; should be ISO 8601 duration like PT1M -> Option B

4. Quick Check:

   Granularity format must be ISO 8601 [OK]

Hint: Use PT1M, not 1m, for granularity [OK]

Common Mistakes:

• Using shorthand time like '1m' instead of 'PT1M'
• Forgetting API key causes 401, not 400
• Using wrong HTTP method causes 405, not 400

5. You want to monitor both CPU and memory usage for your MongoDB cluster every 5 minutes using Atlas API. Which query parameter setup is correct?

hard

A. metricNames=CPU_USER,MEMORY_USAGE&granularity=5minutes

B. metricNames=CPU_USER;MEMORY_USAGE&granularity=5m

C. metricNames=CPU_USER,MEMORY_USAGE&granularity=PT5M

D. metricNames=CPU_USER+MEMORY_USAGE&granularity=PT5M

Solution

1. Step 1: Understand metricNames format

   Multiple metrics are separated by commas, so 'CPU_USER,MEMORY_USAGE' is correct.

2. Step 2: Use correct granularity format

   Granularity must be ISO 8601 duration, so 'PT5M' means 5 minutes.

3. Final Answer:

   metricNames=CPU_USER,MEMORY_USAGE&granularity=PT5M -> Option C

4. Quick Check:

   Comma separates metrics; PT5M means 5 minutes [OK]

Hint: Use commas for metrics and PT5M for 5 minutes [OK]

Common Mistakes:

• Using semicolons or plus signs instead of commas
• Using '5m' or '5minutes' instead of PT5M
• Mixing wrong separators and time formats