Observability Basics

Observability Basics

Step 1 of 13

errors0.6%

Metrics are cheap numbers over time: request rate, error rate, latency percentiles.

The Idea

Metrics are cheap numbers over time — request rate, error rate, latency percentiles — ideal for alerting and useless for detail. Logs record individual events with context, and get expensive at volume. A trace follows one request across every service it touched, which is the only view that finds the slow hop.

Real-World Example

A bus control room runs all three. The wall board shows headway and punctuality; each vehicle's fault log explains one breakdown; and when a complaint lands, somebody follows that single journey through every depot handover to see where the twelve minutes went.

The Tradeoff

All three cost money and attention, and a dashboard nobody reads is worse than none. Watch percentiles rather than averages, keep metric labels low-cardinality — a label per user ID will bankrupt you — and sample traces instead of recording every single request.

Your turn

Put the steps in the right order.

1. 1Open the trace of a slow request to see which hop cost the time↑↓
2. 2An alert fires when the error-rate metric crosses its threshold↑↓
3. 3Read that one service's logs around the failing requests↑↓
4. 4Check the dashboard to see which service the errors come from↑↓

Check order

Mini quiz

1 / 3

Alerting is best built on:

• ARaw log lines
• BAggregated metrics
• CIndividual traces
• DSource code