Platform observability and SLAs in MLOps - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a basic metric for monitoring model latency.

MLOps

model_latency = [1]('model_latency_seconds')

Drag options to blanks, or click blank then click option'

AHistogram

BGauge

CCounter

DSummary

Attempts:

3 left

💡 Hint

Common Mistakes

Using Counter which only counts events, not durations.

A Histogram is used to observe the distribution of latency values over time, which is ideal for model latency monitoring.

2fill in blank

medium

Complete the code to set an alert threshold for SLA violation when error rate exceeds 5%.

MLOps

if error_rate [1] 0.05:
    trigger_alert()

Drag options to blanks, or click blank then click option'

A<=

B<

C>

D==

Attempts:

3 left

💡 Hint

Common Mistakes

Using '<' which triggers alert for low error rates.

The alert triggers when the error_rate is greater than 5% (0.05), indicating SLA violation.

3fill in blank

hard

Fix the error in the Prometheus query to calculate 99th percentile latency.

MLOps

histogram_quantile(0.99, sum(rate([1][5m])) by (le))

Drag options to blanks, or click blank then click option'

Amodel_latency_seconds_sum

Bmodel_latency_seconds_bucket

Cmodel_latency_seconds_count

Dmodel_latency_seconds

Attempts:

3 left

💡 Hint

Common Mistakes

Using raw latency or count metrics instead of buckets.

The histogram_quantile function requires the bucketed histogram metric, which ends with _bucket.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that maps model names to their error rates above 1%.

MLOps

{model: [1] for model, [2] in metrics.items() if error_rate > 0.01}

Drag options to blanks, or click blank then click option'

Aerror_rate

Clatency

Dcount

Attempts:

3 left

💡 Hint

Common Mistakes

Using latency or count instead of error_rate.

We want to map each model to its error_rate when the error rate is above 1%. Both blanks use error_rate.

5fill in blank

hard

Fill all three blanks to filter logs for errors, extract timestamps, and count occurrences.

MLOps

error_counts = {log['[1]']: logs.count([2]) for log in logs if '[3]' in log['message']}

Drag options to blanks, or click blank then click option'

Atimestamp

Blog

Cerror

Dlevel

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'level' instead of 'error' for filtering.

The dictionary keys are timestamps, the count is of the log itself, and the filter checks if 'error' is in the message.

Practice

1. What is the main purpose of platform observability in MLOps?

easy

A. To monitor and understand system performance in real time

B. To set legal contracts with users

C. To deploy machine learning models automatically

D. To store large amounts of data efficiently

Solution

1. Step 1: Understand observability concept

   Observability means seeing how the system behaves and performs live.

2. Step 2: Match purpose with options

   Only To monitor and understand system performance in real time talks about monitoring and understanding performance in real time.

3. Final Answer:

   To monitor and understand system performance in real time -> Option A

4. Quick Check:

   Observability = Real-time performance monitoring [OK]

Hint: Observability = watching system health live [OK]

Common Mistakes:

• Confusing observability with deployment
• Thinking observability sets contracts
• Mixing observability with data storage

2. Which of the following is the correct way to define an SLA uptime of 99.9% in a YAML configuration?

easy

A. sla:
uptime: '99.9%'

B. sla:
uptime: 99.9

C. sla:
uptime: 0.999

D. sla:
uptime: '99,9%'

Solution

1. Step 1: Understand SLA uptime format

   SLA uptime is usually expressed as a percentage string like '99.9%'.

2. Step 2: Check YAML syntax and value correctness

   sla: uptime: '99.9%' uses correct YAML syntax and proper string format with percent sign.

3. Final Answer:

   sla:\n uptime: '99.9%' -> Option A

4. Quick Check:

   Correct SLA uptime format = '99.9%' string [OK]

Hint: Use string with percent sign for SLA uptime [OK]

Common Mistakes:

• Using number without percent sign
• Using decimal instead of percentage
• Using comma instead of dot in percentage

3. Given this monitoring alert rule snippet:

if error_rate > 0.05:
  alert('High error rate')
else:
  alert('Error rate normal')

What will be the alert message if error_rate is 0.03?

medium

A. No alert

B. High error rate

C. Error rate normal

D. Syntax error

Solution

1. Step 1: Evaluate the condition with error_rate = 0.03

   0.03 is less than 0.05, so the condition error_rate > 0.05 is false.

2. Step 2: Determine which alert triggers

   Since condition is false, the else branch runs, triggering alert('Error rate normal').

3. Final Answer:

   Error rate normal -> Option C

4. Quick Check:

   0.03 < 0.05 triggers else alert [OK]

Hint: Check if error_rate exceeds threshold [OK]

Common Mistakes:

• Confusing greater than with less than
• Assuming no alert triggers
• Thinking code has syntax error

4. You have this SLA configuration:

sla:
  uptime: '99.95%'
  response_time_ms: 200

But your monitoring shows frequent alerts for response time exceeding 200ms. What is the most likely cause?

medium

A. The uptime percentage is incorrect

B. The SLA response_time_ms is set too low for actual system performance

C. The SLA syntax is invalid YAML

D. The monitoring tool is not running

Solution

1. Step 1: Analyze SLA and alert mismatch

   The SLA sets response_time_ms to 200ms, but alerts show it often exceeds this.

2. Step 2: Identify cause of frequent alerts

   This means the system often responds slower than 200ms, so SLA is too strict or system needs improvement.

3. Final Answer:

   The SLA response_time_ms is set too low for actual system performance -> Option B

4. Quick Check:

   Strict SLA causes frequent alerts [OK]

Hint: Check if SLA limits match real system speed [OK]

Common Mistakes:

• Blaming uptime for response time alerts
• Assuming YAML syntax error without checking
• Ignoring monitoring tool status

5. You want to combine observability metrics and SLA checks to alert only when uptime drops below 99.9% and error rate exceeds 1%. Which pseudo-code correctly implements this?

hard

A. if uptime >= 99.9 and error_rate >= 0.01:
alert('SLA breach')

B. if uptime > 99.9 or error_rate < 0.01:
alert('SLA breach')

C. if uptime <= 99.9 and error_rate <= 0.01:
alert('SLA breach')

D. if uptime < 99.9 and error_rate > 0.01:
alert('SLA breach')

Solution

1. Step 1: Understand SLA breach conditions

   SLA breach means uptime is less than 99.9% AND error rate is greater than 1% (0.01).

2. Step 2: Match condition logic with options

   if uptime < 99.9 and error_rate > 0.01: alert('SLA breach') uses < for uptime and > for error rate combined with AND, matching the requirement exactly.

3. Final Answer:

   if uptime < 99.9 and error_rate > 0.01:\n alert('SLA breach') -> Option D

4. Quick Check:

   Use AND with correct inequalities for SLA breach [OK]

Hint: Use AND with uptime < 99.9 and error_rate > 0.01 [OK]

Common Mistakes:

• Using OR instead of AND
• Reversing inequality signs
• Alerting on normal conditions