Bird
Raised Fist0
MongoDBquery~30 mins

Monitoring with Atlas metrics in MongoDB - Mini Project: Build & Apply

Choose your learning style10 modes available
Monitoring with Atlas metrics
📖 Scenario: You are managing a MongoDB database hosted on Atlas. You want to monitor the database's performance by collecting key metrics such as CPU usage, memory usage, and operation counts.This helps you keep your database healthy and respond quickly if something goes wrong.
🎯 Goal: Build a simple Python script to filter and display sample Atlas monitoring metrics for CPU usage, memory usage, and operation counts above a threshold.
📋 What You'll Learn
Create a variable called metrics with sample Atlas metrics data as a list of dictionaries.
Create a variable called threshold set to 70 to represent a usage alert level.
Use a for loop with variables metric to iterate over metrics and select only those metrics where metric['value'] is greater than threshold.
Print the filtered list of high usage metrics.
💡 Why This Matters
🌍 Real World
Monitoring database performance is crucial to avoid downtime and ensure smooth user experience. Atlas metrics help track resource usage and operation counts.
💼 Career
DevOps engineers and database administrators use monitoring scripts like this to maintain healthy cloud databases and respond quickly to issues.
Progress0 / 4 steps
1
Create sample Atlas metrics data
Create a variable called metrics and assign it a list of dictionaries with these exact entries: {'name': 'cpuUsage', 'value': 65}, {'name': 'memoryUsage', 'value': 75}, {'name': 'operationCount', 'value': 50}.
MongoDB
Hint

Think of metrics as a list holding small boxes (dictionaries), each with a name and a value.

2
Set the alert threshold
Create a variable called threshold and set it to the integer 70.
MongoDB
Hint

The threshold is a number that tells us when usage is too high.

3
Filter metrics above the threshold
Create an empty list called high_usage_metrics. Use a for loop with variable metric to iterate over metrics. Inside the loop, use an if statement to check if metric['value'] is greater than threshold. If yes, append metric to high_usage_metrics.
MongoDB
Hint

Think of checking each metric's value and collecting only those that are too high.

4
Display the high usage metrics
Write a print statement to display the variable high_usage_metrics.
MongoDB
Hint

The output should show only the metrics with values above 70.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard