Skip to content
Clairos Learn

Observability and tracing · Lesson 5 of 15 · 8 min

Inspect error-rate evidence

An error rate needs both failures and total eligible requests over a stated window. A count of failures without a denominator cannot show the rate.

Mastery 0/3Run itExplain itApply it
learner@clairosSimulated AI Ops lab
learner@clairos:~ $
↑ history · Tab complete · Ctrl+C cancel · Esc, Tab to leaveExit 0

Understand the pattern

An error rate needs both failures and total eligible requests over a stated window. A count of failures without a denominator cannot show the rate.

Interpret the evidence

Report a 1.2 percent error rate for this 1000-request window.

A tempting mistake

Report 12 percent because there were 12 errors.

All names, measurements, prices, versions, and thresholds in this exercise are fictional training data. The evidence supports this bounded scenario, not a claim about a live provider.

Worked example and expected result
$ cat /opt/ai-lab/cases/aiops-observability-tracing-005.json
{
  "fixture": "Fictional training data; not a live measurement.",
  "errors": 12,
  "requests": 1000,
  "error_rate": 0.012
}

Exit status: 0. The command completed successfully in the training fixture.

$ jq .error_rate /opt/ai-lab/cases/aiops-observability-tracing-005.json
0.012

Exit status: 0. The command completed successfully in the training fixture.

$ printf '%s\n' 'report-1-point-2-percent' > /home/learner/lab/aiops-observability-tracing-005-decision.txt
(no output; exit 0)

Exit status: 0. The command completed successfully in the training fixture.

Try a variation

Name the assumption that would have to change for “report-1-point-2-percent” to stop being the justified action. Do not silently replace missing evidence with a guess.

Explain it

What does the evidence in “Inspect error-rate evidence” justify?

Apply it elsewhere

A colleague concludes: “Report 12 percent because there were 12 errors.” What should you do?

Keep the momentum.

Complete the lab, then explain and apply the pattern.

Next: Follow a request traceTry an incident drill

Anonymous lesson and mastery progress lasts for this session. Sign in to keep synced lesson XP between sessions; mastery stays device-local. No speed bonus, lost lives, or hint penalties.

Keep learning

  1. 01Compare throughput signalsRequests per second and tokens per second measure different throughput. Workload length can change token throughput without the same change in request throughput.Practice
  2. 02Follow a request traceA trace follows one request through its spans. Use parent-child relationships and IDs so unrelated concurrent work does not get included in the incident path.Practice
  3. 03Find a slow spanCompare span duration with the total trace and distinguish sequential from overlapping work. A long span is a starting point for investigation, not automatic proof of CPU saturation.Practice