Monitoring & Service Level Indicators

Module 2 of this blueprint told you an SLI is a ratio of good events to valid events. This module is where that ratio actually comes from — the raw telemetry, the two ways of classifying an event as "good," and the exam's insistence that you can tell monitoring and observability apart on sight. It's also where the four golden signals live: the four dimensions Google's Site Reliability Engineering book names as worth watching on almost any service, and the usual raw material an SLI gets built from. Everything here sits directly underneath Service Level Objectives & Error Budgets — that module tells you what to do with an SLI once you have one; this one tells you how to get one in the first place.

Where this module sits, and what the exam actually tests

☺ Like you're 10: This is topic four out of eight on the test, and it's the one about turning raw data into a trustworthy number — not about any specific dashboard tool.

The SRE Foundation (SREF) from the DevOps Institute is a closed-book, 40-question, 60-minute multiple-choice exam with a 65% pass mark, organized around eight syllabus modules. This page covers the fourth: Monitoring and Service Level Indicators, sitting between Reducing Toil (Module 3) and SRE Tools & Automation (Module 5). Unlike some domain-weighted certifications that publish an exact percentage per section, the DevOps Institute doesn't break the 40 questions down by module — treat the table below as your syllabus outline, not a scored weighting, and confirm the current specifics against the accreditor's own courseware before you sit the exam.

Monitoring vs. observability: the distinction the exam draws

☺ Like you're 10: Monitoring answers questions you thought to ask ahead of time. Observability lets you ask a brand-new question after something surprises you, without shipping new code first.

People use these two words interchangeably in casual conversation, and the exam specifically wants you to stop doing that. Monitoring is checking a predefined set of conditions you already decided mattered: CPU above 90%, a health check failing, queue depth above 1,000. It's a dashboard of gauges you chose in advance, built to catch known-unknowns — failure modes you can predict well enough to pre-build a check and a threshold for. Observability is a property of the system itself: how well its external outputs — metrics, logs, traces — let you infer what's happening inside it, including states nobody anticipated. Its job is unknown-unknowns: the rare interaction between two services under one specific traffic pattern, a slow dependency three hops away, a single misbehaving tenant nobody wrote an alert for because nobody knew to.

This distinction only started to matter once systems got distributed. A monolith on one box gave you one place to look; a service mesh with dozens of components and autoscalers reshuffling instances every minute means a single user request fans out across many processes, so "which box is slow?" is often the wrong question — the request itself is the unit that got slow, and it crossed ten hops to get that way. High-cardinality, high-dimensionality telemetry — tagged by user, version, region, and endpoint, not just aggregated into one line on a graph — is what lets you slice that data after the fact along a dimension nobody thought to alert on. Platform Engineering's Observability & Operations module covers the three pillars and their tooling — Prometheus, Loki, OpenTelemetry, Jaeger — in full architectural depth if you want the platform-building side of this same idea; Honeycomb and OpenTelemetry in this course's own tool pages cover the SRE-practitioner angle on the same tooling.

From raw telemetry to a Service Level Indicator

☺ Like you're 10: Telemetry is every number the system produces all day; an SLI is what's left after you decide which of those numbers count as "good," which count at all, and divide one by the other.

This course's foundations page already told you an SLI is good events over valid events. What it didn't cover — and what this module drills on — is where "good" and "valid" actually come from, because the exam likes to test the two source methods and the two aggregation methods separately.

Two sources: black-box and white-box monitoring

Google's Site Reliability Engineering book draws this line at the source of the telemetry, not at what you do with it afterward. Black-box monitoring tests the system from the outside, with no knowledge of its internals — a synthetic HTTP probe hitting /checkout every 30 seconds, a Prometheus blackbox_exporter target, a scripted login-and-purchase flow run from a third-party location. It sees exactly what a real user would see, including problems white-box instrumentation inside your own code can never catch — a DNS misconfiguration, a broken load balancer, an expired TLS certificate. White-box monitoring is built from telemetry the system exposes about its own internal state — a /metrics endpoint, structured application logs, spans emitted by an OpenTelemetry SDK. It gives you the detail black-box probing can't: which specific downstream call is slow, which code path threw the error, which database query is the bottleneck. A well-monitored service uses both — black-box for the outside-in symptom, white-box for the inside-out root cause — and most real SLIs are actually assembled from white-box counters, because you need per-request labels (route, status code) that a simple external probe doesn't have.

Two aggregations: request-based and windows-based SLIs

Once you've got labeled telemetry, there are two standard ways to turn it into a ratio. A request-based SLI counts discrete events directly — every HTTP request either counts as good (non-5xx, under the latency threshold) or bad, and the SLI is good events ÷ valid events over a rolling window. This is the shape almost everyone reaches for first, and it works well whenever the system produces a clean stream of countable events. A windows-based SLI instead buckets time into fixed intervals — say, one-minute windows — and each window as a whole is scored good or bad against a per-window threshold (for example, "no request in this minute exceeded 500ms," or "availability stayed above 99.9% within this minute"). The SLI becomes good windows ÷ total windows. Windows-based SLIs matter for systems that don't produce discrete, individually countable events the way an HTTP API does — a batch pipeline, a streaming job, anything measured more naturally as "was this minute healthy" than "was this one request good" — and they're also a deliberately gentler aggregation: a single terrible request inside an otherwise-fine minute doesn't sink the whole window the way it sinks a request-based ratio. SLO Windows & Composite SLOs goes further into how the choice of window shape and length changes an SLO's behavior in practice.

The four golden signals, as this module's raw material

☺ Like you're 10: Four questions cover almost any service: how fast, how busy, how broken, and how full — and an SLI is almost always built from one or two of these four.

Google's SRE book names four signals worth a dashboard, and usually an alert, on nearly any service you'll ever run: latency (how long a request takes, reported as a distribution — never a single average — and always split by success vs. failure), traffic (demand on the system — requests per second, transactions per second, whatever unit fits), errors (the rate of requests that failed, explicitly or implicitly), and saturation (how full the service is relative to its limit — CPU, memory, queue depth, connection-pool usage). This course's Monitoring & Observability page covers all four in full, along with the USE and RED framings built on top of them and the symptom-vs-cause alerting distinction — read it for the complete treatment; this table is the exam-speed version.

Notice the last row: saturation is essential to watch and essential to alert an engineer on, but on the exam it should almost never be your answer to "name a good SLI." Users don't experience your CPU utilization; they experience the latency and error-rate consequences of it a moment later. That's exactly the same principle the foundations page calls "measure what the user feels," applied here to the raw signal you'd be tempted to promote straight into an SLI without translating it first.

Deriving an SLI, in practice

☺ Like you're 10: Here's what the classification step from the diagram above actually looks like written down as code.

A request-based availability SLI is usually a Prometheus recording rule that pre-computes the ratio so an SLO rule and a burn-rate alert can both read it cheaply:

# "good": non-5xx responses to the checkout route
# "valid": every request to the checkout route (nothing excluded here)
- record: sli:checkout_availability:ratio_rate5m
  expr: |
    sum(rate(http_requests_total{route="/checkout",code!~"5.."}[5m]))
    /
    sum(rate(http_requests_total{route="/checkout"}[5m]))

Tools like Sloth and Nobl9 — both on this course's toolchain — generate exactly this shape of recording rule from a declarative SLO spec, so a practitioner rarely hand-writes the PromQL above in a mature setup; you're still expected to be able to read it and identify the numerator and denominator on the exam. Multi-Window, Multi-Burn-Rate Alerting covers what consumes this exact metric once it exists — how fast the error budget is being spent, and when that rate is fast enough to justify paging someone.

Get the source (black-box or white-box) and the aggregation (request-based or windows-based) right, and the SLI you hand to Module 2 is trustworthy. Get either one wrong — count health-check traffic as valid, or classify a discrete API's events by whole-minute windows when a single slow request should have counted on its own — and every number downstream, including the error budget it feeds, is measuring the wrong thing precisely.