Cram Sheet280 words
Topic 5.2 — Analyzing metrics — cram sheet
Topic 5.2 — Analyzing metrics · cram sheet
Infrastructure indicators
| Indicator | Watch |
|---|---|
| CPU | Saturation — and low CPU with high latency |
| Memory | Growth without plateau (leak); paging |
| Disk | IOPS and queue depth |
| Network | Throughput, retransmits, connection exhaustion |
- Per resource ask: utilisation · saturation (queue) · errors.
- Queueing starts before saturation — 60% with a deep queue is already a bottleneck.
- Low CPU + high latency = waiting, not computing. The shape teams miss.
Analysing telemetry
Order: which operations are slow (p95/p99) → what are they waiting on (dependencies) → where in the code (traces). Starting at profiling answers the wrong question in detail.
Aggregates hide people. A healthy 0.1% global error rate can conceal one tenant failing every request. Segment by operation, region, client version, tenant. Correlate with release annotations — most regressions follow a deployment.
Distributed tracing
- A correlation id propagated across service boundaries stitches spans into one operation.
- A trace that stops partway = missing propagation, not a fast service.
- Tracing separates the service that reports a failure from the one that caused it.
KQL
Shape: source → where → summarize → order by → take
| Operator | Does |
|---|---|
where | Filter |
summarize | Aggregate — count(), avg(), percentile() |
bin() | Bucket timestamps for time series |
project / extend | Choose / add columns |
join | Combine tables |
Filter early, especially on time — less data scanned, cheaper and faster.
percentile(duration, 95) is the latency view averages hide.