Enter your traffic and what tracing costs you. See, for any sampling rate, how much you store and pay — and how likely you are to have a trace of the rare failure you will be asked about.
Runs entirely in your browser — nothing you enter here is sent to a server.
A distributed trace records the path of one request through every service it touches, as a tree of spans. It is the most detailed telemetry you can collect and the most expensive: a single request can produce dozens of spans, and at a few hundred requests per second that becomes hundreds of gigabytes a day. Almost all of those traces describe requests that were fast and successful and that nobody will ever look at.
Sampling means keeping only some of them. The question is how few you can keep while still having an example when you need one. That depends less on your traffic than on how rare the interesting thing is: at a 1% sampling rate, an error affecting 1 request in 1,000 is captured once in every 100,000 requests.
The decision is made at the start of the request, at random. Cheap and simple, works everywhere — but blind: it drops errors at the same rate as everything else.
The decision is made after the trace is complete, so you can keep all errors and slow requests. Needs a collector that buffers whole traces.
Keep at most N traces per second per service. Protects the budget during traffic spikes, when percentage sampling would flood the backend.
Sample health checks at 0%, the checkout at 100% and everything else at a few percent. The cheapest improvement available.
High-traffic services need a lower percentage than quiet ones for the same coverage, because what matters is the absolute number of traces. A useful rule: pick the rate that gives you at least a few dozen examples per day of the rarest event you care about. If that costs too much, the answer is tail sampling, not a lower rate. And keep metrics unsampled — request counts and error rates should always come from all requests, never be estimated from traces.
It depends on traffic. Under 10 requests per second, keep everything. At hundreds per second, 1–10% with head sampling is typical. At thousands, use tail sampling and keep under 1% of ordinary traces plus all errors.
Head sampling decides at the start of a request, before anything is known about it. Tail sampling decides once the trace has finished, so it can keep traces with errors or high latency and drop routine ones.
With head sampling, yes — errors are dropped in the same proportion as everything else. Use tail sampling, or record errors as metrics and logs so they are counted even when the trace is dropped.
It should not. Generate request rate, error rate and latency metrics from all requests, before sampling. Metrics derived from sampled traces must be scaled up and are less accurate for rare events.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.