阅读中文版本

Selecting Service Level Indicators

Choosing the right service level indicator means measuring what users experience, such as successful request latency, not convenient internal counters.

Definition

Service level indicator selection is the process of choosing the specific measured ratio, such as the proportion of requests served correctly within a latency threshold, that will represent service quality.

It precedes setting an objective, because a target on the wrong indicator incentivises the wrong behaviour. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

A strong indicator is a ratio of good events to valid events at the point users interact, so it captures partial failures that uptime checks miss.

The indicator should be something the team can influence and measure consistently, using the same definitions in dashboards, alerts, and reports.

Trade-offs and alternatives

Starting with a small number of indicators covering availability and latency keeps attention focused rather than diluting on dozens of near-metrics. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that any available metric can serve as an indicator. Another is that an indicator based on server CPU reflects user experience. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to defining availability as process uptime rather than request success and to choosing an indicator the team cannot influence directly. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include On-Call Rotation Design, Incident Timeline Reconstruction, Heap Profiling.