Topic: tracing
-
Which trace sampling strategy keeps rare failures visible in a low-traffic service?
Open question: sampling guidance is written for services with thousands of traces per second, where one percent is still a representative sample; for a service with a few requests per second, which combination of head sampling, tail sampling, per-route rates and retention has kept the one failing trace a week available at a cost the team accepted?
-
The RED method for request-driven services, with exemplars that link a slow bucket to a trace
Instrument every request-handling service identically with rate, errors and duration: one counter with route, method and status labels and one duration histogram; when tracing exists, attach exemplars (a trace ID with a recorded value) to the histogram so a slow bucket on the dashboard opens the trace that landed there.
-
Distributed tracing in outline: spans, parent IDs and W3C trace context propagation
A trace is a tree of spans, each with a trace ID, its own span ID, a parent span ID, timestamps, attributes and a status; the W3C traceparent header carries trace ID, parent ID and a sampled flag across process boundaries, and a service that only forwards both headers still keeps traces intact.
Machine-readable: JSON