Observability and tracing
Use logs, metrics, traces, request identifiers, latency percentiles, and error budgets to explain behavior.
What you will practice
Read an observability map; Inspect gateway metrics; Read latency percentiles; Compare throughput signals.
Use the worked examples when needed, then test your understanding without them.
- 01Read an observability mapLogs, metrics and traces answer different questions. Combine a metric trend with a trace and targeted logs instead of treating any single view as the complete explanation.Practice
- 02Inspect gateway metricsMetrics need units, scope and a time window. Counters, rates and gauges should not be compared as though they measured the same thing.Practice
- 03Read latency percentilesA p95 latency describes a percentile within an observed window. It does not mean that every request or the average request has that latency.Practice
- 04Compare 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
- 05Inspect error-rate evidenceAn error rate needs both failures and total eligible requests over a stated window. A count of failures without a denominator cannot show the rate.Practice
- 06Follow 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
- 07Find 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
- 08Connect logs and tracesLogs and traces correlate through stable identifiers, not approximate timestamps alone. Keep the relevant request and span identifiers in diagnostic events.Practice
- 09Inspect token metricsToken metrics help distinguish input growth from output growth. A cost or latency increase can follow a longer context even when the response length remains stable.Practice
- 10Review model saturationSaturation combines utilization, queueing and service time. High utilization without queue growth can mean useful work; a growing queue gives the observation operational context.Practice
- 11Read an SLO windowAn SLO defines a target and window for a user-visible measure. Read the denominator and exclusions before comparing current behavior to the target.Practice
- 12Calculate error-budget postureError-budget posture compares observed bad events with the allowance implied by the SLO. Record the window and avoid mixing request-based and time-based budgets.Practice
- 13Build an incident timelineAn incident timeline preserves ordering, versions and the distinction between observations and interventions. Use timestamps with a shared timezone or offset.Practice
- 14Prepare an observability summaryAn observability summary should name the symptom, scope, supporting signals and uncertainty. A concise note is useful only if its key claims can be checked.Practice
- 15Observability checkpointA complete observation ties metric, unit, window and scope to a next investigation. Do not combine unrelated signals simply to make a compelling story.Practice