API monitoring and alerting in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this curl command?

You run this command to check an API endpoint status:

curl -s -o /dev/null -w "%{http_code}" https://api.example.com/status

What output will this command produce if the API is healthy?

Rest API

curl -s -o /dev/null -w "%{http_code}" https://api.example.com/status

A 500

B OK

C 404

D 200

💡 Hint

The command outputs the HTTP status code only.

The curl command with -w "%{http_code}" prints the HTTP status code. 200 means success.

🧠 Conceptual

intermediate

Which alert condition best detects API downtime?

You want to create an alert for your API monitoring tool. Which condition below best detects when the API is down?

A Alert if HTTP status code is 500 or 503

B Alert if response time > 1 second

C Alert if API returns any 2xx status code

D Alert if API response body contains 'success'

💡 Hint

Server errors indicate downtime or failure.

HTTP 500 and 503 status codes indicate server errors or service unavailable, signaling downtime.

❓ Configuration

advanced

Which Prometheus alert rule triggers on high API error rate?

Given this Prometheus metric: api_request_errors_total counts API errors, and api_requests_total counts total requests.
Which alert rule triggers if error rate exceeds 5% over 5 minutes?

A

alert: HighApiErrors
expr: (rate(api_request_errors_total[5m]) / rate(api_requests_total[5m])) > 0.05
for: 5m

B

alert: HighApiErrors
expr: rate(api_request_errors_total[5m]) > 0.05
for: 5m

C

alert: HighApiErrors
expr: api_request_errors_total / api_requests_total > 0.05
for: 5m

D

alert: HighApiErrors
expr: sum(api_request_errors_total) > 5
for: 5m

💡 Hint

Use rate() to calculate per-second increase over time.

Option A calculates the error rate as the ratio of error requests to total requests over 5 minutes using rate(), then triggers if above 5%.

❓ Troubleshoot

advanced

Why does this alert never trigger?

You configured an alert:

alert: ApiDown
expr: up{job="api"} == 0
for: 10m

But it never triggers even when the API is down. What is the likely cause?

A The expression should use '!=' instead of '=='

B The 'for' duration is too short to trigger

C The 'up' metric is missing or not scraped for the API job

D The alert name must be lowercase

💡 Hint

Check if the metric used in expr is available.

If the 'up' metric is not scraped for the API job, the expression never evaluates to true, so alert never fires.

🔀 Workflow

expert

Order the steps to set up API monitoring with alerting

Arrange these steps in the correct order to set up API monitoring and alerting:

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Think about defining what to measure before collecting data.

First define what to measure, then collect data, then create alerts, finally test them.

Practice

1. What is the main purpose of API monitoring in DevOps?

easy

A. To design the API user interface

B. To write new API endpoints

C. To regularly check if the API is working correctly

D. To store API data permanently

Solution

1. Step 1: Understand API monitoring

   API monitoring means checking the API often to see if it works well without errors.

2. Step 2: Identify the main goal

   The main goal is to ensure the API is available and responds correctly to requests.

3. Final Answer:

   To regularly check if the API is working correctly -> Option C

4. Quick Check:

   API monitoring = regular checks [OK]

Hint: Monitoring means checking often if API works [OK]

Common Mistakes:

• Confusing monitoring with API design
• Thinking monitoring stores data
• Mixing monitoring with coding new endpoints

2. Which of the following is the correct way to set up an alert for API downtime in a monitoring tool?

easy

A. Trigger alert if API response time is less than 100ms

B. Trigger alert if API documentation changes

C. Trigger alert if API returns status code 200

D. Trigger alert if API returns status code 500 or no response

Solution

1. Step 1: Understand alert conditions for downtime

   An alert for downtime should trigger when the API fails or does not respond, such as status code 500 or no response.

2. Step 2: Evaluate options

   Trigger alert if API returns status code 500 or no response correctly triggers alert on error or no response. Other options either alert on success or unrelated events.

3. Final Answer:

   Trigger alert if API returns status code 500 or no response -> Option D

4. Quick Check:

   Alert on errors or no response = Trigger alert if API returns status code 500 or no response [OK]

Hint: Alert on errors or no response, not success [OK]

Common Mistakes:

• Alerting on successful responses
• Alerting on unrelated changes like docs
• Using wrong status codes for alerts

3. Given this monitoring script snippet:

response = requests.get('https://api.example.com/data')
if response.status_code != 200:
    send_alert('API error detected')

What happens if the API returns status code 404?

medium

A. No alert is sent

B. An alert is sent with message 'API error detected'

C. The script crashes with an error

D. The script retries the request automatically

Solution

1. Step 1: Analyze the condition in the script

   The script sends an alert if the status code is not 200.

2. Step 2: Check the status code 404

   Since 404 is not 200, the condition is true and alert is sent.

3. Final Answer:

   An alert is sent with message 'API error detected' -> Option B

4. Quick Check:

   Status code 404 triggers alert [OK]

Hint: Alert triggers if status code not 200 [OK]

Common Mistakes:

• Thinking 404 is success
• Assuming script crashes on 404
• Believing script retries automatically

4. You wrote this alert rule:

if response.status_code = 500:
    send_alert('Server error')

Why does this rule not work as expected?

medium

A. The comparison operator should be '==' not '='

B. The status code 500 is not an error

C. send_alert function is missing parentheses

D. The API URL is missing

Solution

1. Step 1: Identify the operator used

   The code uses '=' which is assignment, not comparison.

2. Step 2: Correct operator for comparison

   To compare values, '==' must be used instead of '='.

3. Final Answer:

   The comparison operator should be '==' not '=' -> Option A

4. Quick Check:

   Use '==' for comparison [OK]

Hint: Use '==' to compare values, '=' assigns [OK]

Common Mistakes:

• Using '=' instead of '==' in conditions
• Thinking 500 is not an error
• Ignoring syntax errors in conditions

5. You want to monitor an API that sometimes returns status 429 (too many requests) temporarily. Which alerting strategy best avoids false alarms?

hard

A. Alert only if 429 responses occur continuously for 5 minutes

B. Alert immediately on any 429 response

C. Ignore 429 responses completely

D. Alert only if 429 responses are followed by 200 responses

Solution

1. Step 1: Understand 429 status meaning

   Status 429 means too many requests temporarily; it may resolve quickly.

2. Step 2: Choose alerting strategy to avoid false alarms

   Alerting immediately on one 429 may cause false alarms; waiting for continuous 429s for 5 minutes reduces noise.

3. Final Answer:

   Alert only if 429 responses occur continuously for 5 minutes -> Option A

4. Quick Check:

   Delay alerts on temporary errors to reduce false alarms [OK]

Hint: Wait before alerting on temporary errors [OK]

Common Mistakes:

• Alerting immediately on every 429
• Ignoring 429 which may hide real issues
• Alerting on 429 followed by success