Monitoring with Atlas metrics in MongoDB - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is MongoDB Atlas Metrics used for?

MongoDB Atlas Metrics helps you watch how your database is doing by showing important numbers like CPU use, memory, and database operations.

beginner

Name three key metrics you can monitor in MongoDB Atlas.

You can monitor CPU usage, memory usage, and operation counts like reads and writes.

intermediate

How can you access MongoDB Atlas metrics?

You can access metrics through the Atlas web interface or by using the Atlas API to get data programmatically.

beginner

What is an alert in MongoDB Atlas monitoring?

An alert is a message that tells you when a metric goes beyond a limit you set, so you can fix problems quickly.

beginner

Why is monitoring with Atlas metrics important?

It helps keep your database healthy by spotting issues early, so your apps run smoothly without surprises.

Which of these is NOT a metric you can monitor in MongoDB Atlas?

A User login passwords

B CPU usage

C Disk I/O

D Memory usage

MongoDB Atlas metrics include CPU, memory, and disk I/O, but never sensitive data like user passwords.

How can you get MongoDB Atlas metrics data programmatically?

A By email reports only

B By SSH into the server

C Using FTP

D Using the Atlas API

Atlas provides an API to access metrics data programmatically.

What does an alert in MongoDB Atlas do?

A Deletes old data

B Automatically fixes errors

C Notifies when a metric crosses a threshold

D Backs up the database

Alerts notify you when a metric goes beyond a set limit.

Which metric helps you understand how busy your database is?

A CPU usage

B Operation counts (reads/writes)

C Memory usage

D Network latency

Operation counts show how many reads and writes your database is handling.

Where can you view MongoDB Atlas metrics?

A Atlas web interface

B Local text files only

C Command line without API

D Mobile app only

Atlas metrics are available in the web interface and via API.

Explain how MongoDB Atlas metrics help maintain database health.

Think about how watching numbers can prevent problems.

Describe the steps to set up an alert in MongoDB Atlas for high CPU usage.

Focus on the process from metric selection to alert notification.

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