Monitoring with Atlas metrics in MongoDB - Time & Space Complexity

Time Complexity: Monitoring with Atlas metrics

O(n)

Understanding Time Complexity

When monitoring MongoDB with Atlas metrics, we want to understand how the cost of gathering and processing metrics changes as the amount of data grows.

We ask: How does the time to collect and analyze metrics scale with the number of monitored database operations?

Scenario Under Consideration

Analyze the time complexity of this MongoDB aggregation to get operation counts per collection.

    db.system.profile.aggregate([
      { $match: { ns: { $exists: true } } },
      { $group: { _id: "$ns", count: { $sum: 1 } } },
      { $sort: { count: -1 } }
    ])
    

This code groups profiling data by namespace (collection) and counts operations per collection, then sorts by count.

Identify Repeating Operations

Look for repeated work done on data.

• Primary operation: Scanning all profiling documents to group by collection.
• How many times: Once per profiling document, which grows with the number of operations logged.

How Execution Grows With Input

As the number of profiling documents increases, the aggregation must process each one.

Input Size (n)	Approx. Operations
10	About 10 document reads and group updates
100	About 100 document reads and group updates
1000	About 1000 document reads and group updates

Pattern observation: The work grows roughly in direct proportion to the number of profiling entries.

Final Time Complexity

Time Complexity: O(n)

This means the time to process metrics grows linearly with the number of profiling records.

Common Mistake

[X] Wrong: "The aggregation runs instantly no matter how many profiling entries exist."

[OK] Correct: Each profiling document must be read and processed, so more data means more work and longer time.

Interview Connect

Understanding how monitoring queries scale helps you design efficient dashboards and alerts that stay fast as your data grows.

Self-Check

What if we added an index on the "ns" field? How would that affect the time complexity of this aggregation?

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