Monitoring and observability in Prompt Engineering / GenAI - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the difference between monitoring and observability

Which statement best describes the difference between monitoring and observability in a software system?

A Monitoring collects predefined metrics and alerts on known issues, while observability enables understanding unknown issues by analyzing logs, metrics, and traces.

B Monitoring is only about logging errors, and observability is about fixing bugs automatically.

C Monitoring and observability are the same; both only collect logs for debugging.

D Observability is a tool, and monitoring is a process that runs inside it.

💡 Hint

Think about how each helps with known vs unknown problems.

Monitoring focuses on collecting specific metrics and alerting on known issues. Observability provides deeper insight by combining logs, metrics, and traces to understand unknown problems.

💻 Command Output

intermediate

Prometheus query output interpretation

Given the Prometheus query rate(http_requests_total[5m]), what does the output represent?

A The number of HTTP requests in the last 5 seconds.

B The total number of HTTP requests since the server started.

C The average number of HTTP requests per second over the last 5 minutes.

D The current number of active HTTP connections.

💡 Hint

Consider what rate() function calculates in Prometheus.

The rate() function calculates the per-second average increase of a counter over the specified time window, here 5 minutes.

❓ Configuration

advanced

Configuring alert rules in Prometheus

Which Prometheus alert rule configuration will correctly trigger an alert when CPU usage exceeds 80% for 5 minutes?

Prompt Engineering / GenAI

groups:
- name: cpu_alerts
  rules:
  - alert: HighCPUUsage
    expr: avg(rate(cpu_seconds_total[1m])) by (instance) > 0.8
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "CPU usage is above 80%"
      description: "Instance {{ $labels.instance }} CPU usage is above 80% for more than 5 minutes."

A

expr: avg_over_time(cpu_seconds_total[5m]) > 0.8
for: 1m

B

expr: sum(cpu_seconds_total) by (instance) > 80
for: 5m

C

expr: rate(cpu_seconds_total[5m]) > 0.8
for: 5m

D

expr: avg(rate(cpu_seconds_total[1m])) by (instance) > 0.8
for: 5m

💡 Hint

Look for the expression that calculates CPU usage rate averaged per instance over a short interval and checks if it exceeds 0.8 (80%).

Option D uses avg(rate(cpu_seconds_total[1m])) by (instance) which calculates the average CPU usage rate per instance over 1 minute, then alerts if above 0.8 for 5 minutes.

❓ Troubleshoot

advanced

Diagnosing missing logs in a distributed tracing system

You notice that some traces in your distributed tracing system are missing logs from certain services. What is the most likely cause?

A The logs are stored but the dashboard is not refreshing automatically.

B The services are not instrumented properly to send logs to the tracing system.

C The network is blocking all traffic except metrics data.

D The tracing system is down and cannot receive any data.

💡 Hint

Think about what is required for logs to appear in traces from each service.

If services are not instrumented correctly, they won't send logs to the tracing system, causing missing logs in traces.

🔀 Workflow

expert

Order the steps to implement observability in a new microservices project

Arrange the following steps in the correct order to implement observability effectively in a new microservices project.

A 2,1,3,4

B 1,2,3,4

C 2,3,1,4

D 3,2,1,4

💡 Hint

Start by defining goals, then instrument, then collect data, then alert.

First define KPIs and SLOs to know what to measure, then instrument services, set up collection platform, and finally create alerts.

Practice

1. What is the main purpose of monitoring in a software system?

easy

A. To check if the system is working right now

B. To predict future system failures

C. To change system configurations automatically

D. To write new features for the system

Solution

1. Step 1: Understand monitoring's role

   Monitoring is about checking the current state of the system to see if it is working properly.

2. Step 2: Compare options to definition

   Only To check if the system is working right now matches this purpose. Other options describe different activities like prediction, automation, or development.

3. Final Answer:

   To check if the system is working right now -> Option A

4. Quick Check:

   Monitoring = check current system state [OK]

Hint: Monitoring = check system now, not future or changes [OK]

Common Mistakes:

• Confusing monitoring with observability
• Thinking monitoring predicts future issues
• Assuming monitoring changes system behavior

2. Which of the following is a correct example of a monitoring tool?

easy

A. Visual Studio Code

B. Prometheus

C. Dockerfile

D. GitHub

Solution

1. Step 1: Identify monitoring tools

   Prometheus is a popular open-source monitoring tool used to collect and query metrics.

2. Step 2: Check other options

   GitHub is for code hosting, Dockerfile is for container setup, and Visual Studio Code is a code editor, none are monitoring tools.

3. Final Answer:

   Prometheus -> Option B

4. Quick Check:

   Prometheus = monitoring tool [OK]

Hint: Prometheus is a classic monitoring tool name [OK]

Common Mistakes:

• Confusing code tools with monitoring tools
• Thinking Dockerfile is a monitoring tool
• Mixing development tools with monitoring

3. Given this Prometheus query: up{job="api-server"} == 1, what does it show?

medium

A. The total number of api-server jobs

B. All api-server jobs that are down

C. All api-server jobs that are currently up (running)

D. The CPU usage of api-server jobs

Solution

1. Step 1: Understand the query meaning

   The metric up is 1 when a target is up (running), 0 if down. The filter {job="api-server"} selects only api-server jobs.

2. Step 2: Interpret the comparison

   The query checks where up == 1, so it shows api-server jobs currently running.

3. Final Answer:

   All api-server jobs that are currently up (running) -> Option C

4. Quick Check:

   up == 1 means running targets [OK]

Hint: up == 1 means service is running [OK]

Common Mistakes:

• Thinking up == 1 means down
• Confusing metric with count
• Assuming it shows CPU usage

4. You see this error in your monitoring setup: error parsing query: unexpected token. What is the most likely cause?

medium

A. Server hardware failure

B. Network failure between server and client

C. Monitoring tool is not installed

D. Syntax error in the query expression

Solution

1. Step 1: Analyze the error message

   The message says "error parsing query" and "unexpected token", which means the query syntax is wrong.

2. Step 2: Rule out other causes

   Network failure, missing tool, or hardware failure would cause different errors, not parsing errors.

3. Final Answer:

   Syntax error in the query expression -> Option D

4. Quick Check:

   Parsing error = syntax mistake [OK]

Hint: Parsing errors mean syntax mistakes in queries [OK]

Common Mistakes:

• Assuming network or hardware issues cause parsing errors
• Ignoring the error message details
• Thinking the tool is missing

5. You want to improve observability by adding tracing to your microservices. Which approach best helps you understand why requests fail inside your system?

hard

A. Use distributed tracing to follow requests across services

B. Add more CPU and memory to servers

C. Increase the frequency of monitoring alerts

D. Write more unit tests for each service

Solution

1. Step 1: Understand observability and tracing

   Observability helps explain why things happen. Distributed tracing tracks requests across services to find where failures occur.

2. Step 2: Evaluate options for observability

   Adding resources or alerts or tests does not directly show why requests fail inside the system.

3. Final Answer:

   Use distributed tracing to follow requests across services -> Option A

4. Quick Check:

   Tracing = understand request flow and failures [OK]

Hint: Tracing shows request path and failure reasons [OK]

Common Mistakes:

• Confusing monitoring alerts with observability
• Thinking hardware upgrades improve observability
• Assuming tests replace tracing