Before we talk about doing sampling consistently, we need to be clear about why we sample in the first place.

Modern software is rarely one program. A single click on a shopping website may touch a web gateway, a login service, a catalogue service, a pricing service, a payment service, and several databases. To understand what happened during that click, engineers record a trace, which is the full story of the request, made of many small pieces called spans. Each span describes one step, such as one function call, one database query, or one network request, and records when it started, how long it took, and whether it succeeded.

Recording every span for every request is the dream of every engineer and the nightmare of every finance team. A busy system can create millions of spans every minute. Each span has to be built in memory, sent over the network, received by a collector, processed, stored, indexed, and later searched. Each of those steps costs processor time, network bandwidth, disk space, and money. At large scale, the bill for keeping everything can rival the bill for running the actual product.

The key promise of sampling is representativeness. If you keep one trace out of every hundred, and you keep them fairly, then what you see in the kept traces should resemble what happens in all of them. You can still find slow requests, still see typical error patterns, and still estimate how many requests of each kind happened. The word fairly is doing a lot of work in that sentence, and the rest of this tutorial is about what fairness means when many independent programs have to cooperate.

Every new term below comes with what it is, why it exists, where you meet it, and a picture to hold in your head.

A word of caution about the word “head”

The word head sampling is used in two slightly different ways in the industry. Sometimes it means the exact moment a tracing library creates a new span and decides whether to record it. Other times it describes a whole style of tracing setup in which every child follows its parent’s decision, so the choice made at the very start of the trace governs everything after it. When someone says they use head sampling, it is worth asking which meaning they have in mind. Tail sampling, similarly, may mean thinning individual spans as they pass through a collector, or it may mean waiting to assemble a whole trace and then deciding about the entire thing at once.

To appreciate the cure, let us feel the pain of the disease with real numbers.

Suppose a request travels through five services, and every service keeps a span with a probability of fifty percent, deciding by its own private coin flip. For the trace to be complete, all five coins must come up heads. The chance of that is one half multiplied by itself five times, which is about three percent, or roughly one trace in thirty-two. The other thirty-one traces are partial: they have some spans but not others, which means they are full of missing pieces and broken parent-child links.

It gets dramatically worse as the keep rate falls. Real systems rarely keep half of their traces. If each of the five services keeps ten percent, the chance that all five happen to keep the same request is one in a hundred thousand. You would pay to store spans from almost every request, yet nearly every stored trace would be unusable.

flowchart LR
    A["Gateway: coin flip says KEEP"] --> B["Login service: coin flip says DROP"]
    B --> C["Catalogue service: coin flip says KEEP"]
    C --> D["Payment service: coin flip says DROP"]
    D --> E["Database: coin flip says KEEP"]
        

There is a second, quieter problem. Even when you do not care about complete traces, you often want to count things from sampled data, for example to estimate how many payments were attempted. If different services keep spans at different rates and the data does not record those rates, any total you compute will be wrong in an unknowable way. A trustworthy count needs to know the keep probability that applied to each span.

The whole mechanism rests on two ingredients and one comparison.

The first ingredient is a shared random number, called the randomness value. It is created once, when the trace begins, and every participant that touches the trace can read it. The second ingredient is a personal cut-off line, called the rejection threshold. Each participant chooses its own cut-off according to how much data it wants to keep. The comparison is a single question: is the shared number at or above my cut-off? If yes, keep the span. If no, drop it.

Notice how little is required. There is no central coordinator, no shared database, and no network call to ask what others decided. The only shared thing is a number that travels with the request anyway, inside the trace context. This is what makes the idea practical: it adds almost no cost to the request, yet it gives every participant the power to make decisions that fit together.

Everything depends on this number being truly random and truly shared, so let us look at where it comes from.

The randomness value, often written as R, is a 56-bit number. A bit is a single zero or one, so 56 bits give about seventy-two quadrillion possible values. That is a very large range, which matters because the range limits how finely you can express a keep rate. With 56 bits, you can sample at probabilities as small as two raised to the power of minus fifty-six, far smaller than anyone realistically needs.

OpenTelemetry supports two places where this number can live.

Why the trace identifier can be used

The W3C Trace Context standard, in its second level, defines a flag that a tracing library can set to promise that the trace identifier’s last seven bytes were generated randomly. This is called the trace random flag. When the flag is present, any downstream participant can safely read those seven bytes as the shared lucky number without any additional header. When it is absent, a participant cannot be sure, so it should not assume randomness and may rely on an explicit value instead.

Who is allowed to create or change the number

The rule is strict and simple: only the root sampling decision, the very first one in a trace, may create or change the explicit randomness value. Everyone after that must pass the same value along unchanged. If a middle service replaced the number, then services before and after it would be comparing their thresholds against different numbers, and the neat agreement would be destroyed. A consistent system is only as consistent as its most careless participant.

If the randomness value is the lucky number, the threshold is the line you draw on the number ruler to separate keep from drop.

The rejection threshold, often written as T, is also a 56-bit number, and it is derived directly from the keep probability a sampler wants. The name tells you its meaning: it is the count of values, out of all the possible ones, that will be rejected. If you want to keep a quarter of spans, you reject three quarters of the number range, so the cut-off sits three quarters of the way up the ruler. Everything below that line is dropped, and everything at or above the line is kept.

In words, the formula is short: take one minus the keep probability, and multiply it by the size of the whole range, which is two raised to the power fifty-six. The extreme cases are easy to remember. Keeping everything gives a threshold of zero, because nothing is rejected. Keeping a tiny sliver gives a threshold very close to the top of the range.

Valid range and the “never” trap

Sampling probability in OpenTelemetry is valid from two raised to the power of minus fifty-six up to exactly one. Zero is deliberately not part of the range. The reason is conceptual: a rule that never keeps anything is not a probability sampler at all, because it keeps no data from which anything could be estimated. A sampler that drops everything is a perfectly legitimate configuration choice, but it is not a form of probability sampling and it does not carry a threshold.

How a threshold looks when written down

Thresholds are written as hexadecimal numbers, which is a compact way of writing big numbers using the digits zero to nine and the letters a to f. Trailing zeros are removed to save space, which also means the writer can choose how precise to be. Here is how common keep rates look when written with four digits of precision.

Two patterns are worth noticing. Powers of two, like one half or one quarter, produce short, clean thresholds. Other rates, like one in ten, never divide evenly into binary, so the digits repeat and the writer has to decide where to stop. And as the keep rate gets smaller, the threshold starts with more and more f characters, which is just the number creeping closer to the top of the range.

The rule is one comparison, and it is worth practising it on a friendly small ruler before trusting it on a giant one.

The entire decision is this: if the randomness value is greater than or equal to the threshold, keep the span; otherwise drop it. To make the arithmetic easy, let us shrink the giant 56-bit range into a simple ruler from zero to one hundred. A keep probability of fifty percent means a threshold of fifty. A keep probability of twenty percent means a threshold of eighty, because eighty percent of the ruler is rejected. A keep probability of ninety percent means a threshold of ten.

Now imagine four requests arriving, each with its own random number: 12, 55, 83 and 97. We have three samplers, with different keep rates. Look at which requests each one keeps.

Read the table column by column and then row by row. Sampler C keeps the fewest requests, and every request it keeps is also kept by B and by A. Sampler B keeps more, and everything it keeps is also kept by A. There is no request that C keeps while B drops. This staircase pattern, in which the more selective sampler always keeps a subset of what the less selective sampler keeps, is the mathematical heart of the whole system.

flowchart TD
    S["Span arrives with shared random number R"] --> Q{"Is R at or above my threshold T?"}
    Q -->|"Yes"| K["Keep the span and record T"]
    Q -->|"No"| D["Drop the span"]
        

Does the fairness hold?

If the random number is truly uniform, meaning every value is equally likely, then the fraction of requests with a number at or above the threshold equals the keep probability. For the ninety-percent sampler above, ninety out of every hundred requests will have a number of ten or more. The rule therefore delivers exactly the keep rate the operator asked for, on average, while making the decisions line up perfectly across different samplers.

Now that we have seen it in action, we can say exactly what consistent means.

The specification defines a consistent sampling decision like this: if a span is kept by a sampler using probability p1, then every span belonging to the same trace is also kept by any sampler using a probability p2 that is greater than or equal to p1. In plain language, the keep decisions are nested, like a set of Russian dolls. The group kept by the strictest sampler fits inside the group kept by the next strictest sampler, which fits inside the group kept by the most generous one.

What this buys you in practice

graph TD
    A["All spans"] --> B["Kept at 50 percent: threshold 8"]
    B --> C["Kept at 25 percent: threshold c"]
    C --> D["Kept at 10 percent: threshold e666"]
    D --> E["Kept at 1 percent: threshold fd70a"]
        

One more point deserves emphasis. Consistency does not require every service to use the same keep rate. It only requires that they all compare against the same random number. That freedom is what lets teams tune cost per service while still ending up with traces that make sense when they are stitched back together.

Numbers are only useful if they reach the next participant, so we need a place to carry them.

Distributed tracing already passes a small packet of context from service to service with every request. One part of that packet, defined by the W3C Trace Context standard, is the trace state, a list of vendor-specific entries. Each entry has a short key naming the vendor or project and a value that the owner is free to define. OpenTelemetry reserves the key ot for itself, and inside that value it defines small named sub-keys. Two of them matter for sampling.

Three details that confuse beginners

Because the information lives in an ordinary header that already travels with every request, no new network path is introduced. Services that do not understand the OpenTelemetry entry simply pass it along, which is the usual behaviour for trace state entries, so mixed systems keep working even when only some participants are upgraded.

A span can be judged more than once in its life, and understanding when helps you place each sampler in the picture.

The specification describes two kinds of stages. The first is parent and child sampling, which happens inside the tracing library while a request is still running. These decisions follow the direction of cause and effect: the first span decides, and its children usually follow. The second is downstream sampling, which happens after spans have finished and are travelling through a collection pipeline of agents and gateways. A finished span has therefore been judged exactly once by a parent and child sampler and zero or more times by downstream samplers.

flowchart LR
    subgraph SDK["Inside the application: parent and child stage"]
        R["Root span decides"] --> C1["Child span follows"] --> C2["Grandchild follows"]
    end
    subgraph PIPE["Collection pipeline: downstream stage"]
        AG["Agent collector"] --> GW["Gateway collector"] --> ST["Storage backend"]
    end
    C2 --> AG
        

Why the two stages are treated differently

Inside the application, decisions are made live, while the request is in flight, and they can only use information that exists at that moment. Downstream, spans are historical records. A collector can look at a finished span, notice that it was slow or failed, and make a smarter choice, but it must also respect a rule that does not apply inside the application: it may only raise the threshold, never lower it. We will see why in Chapter 13.

Before diving into the finer rules, let us map the cast of characters and the job each one performs.

Consistent probability sampling is not one single program. It is a shared agreement among several components, each doing a small, well-defined job. Seeing all of them on one page makes the later rules much easier to follow.

flowchart LR
    subgraph APP["Application process"]
        SP["Span creation"] --> SM["Sampler: compare R with T"]
        SM --> EX["Exporter"]
    end
    SM --> PR["Propagator writes context with th and rv"]
    PR --> NEXT["Next service in the request path"]
    EX --> AGT["Collector agent"]
    AGT --> GWY["Collector gateway"]
    GWY --> BE["Backend: store spans with thresholds"]
        

Real configurations are built out of a few simple building blocks, each behaving differently with respect to the shared number.

Within the parent and child stage, the specification identifies three primary base cases. Learning these three gives you the vocabulary to read almost any sampler configuration.

Choosing among them

Collectors can thin data further, but they must follow one rule above all others: the threshold can only go up.

Why can a downstream sampler raise a threshold but never lower it? Because lowering would be a lie. A span that arrives with a recorded threshold has already survived a stage with a particular keep probability. Pretending that the stage had been more generous than it really was, by lowering the recorded number, would claim that other spans had been kept when they were in fact thrown away earlier. Any count computed from such a claim would be too small. Raising the threshold, on the other hand, honestly records that an extra round of thinning happened.

The specification names two standard styles of downstream probability sampler.

The equalizing sampler

An equalizing sampler wants every span leaving it to carry the same threshold. If an incoming span already has a higher threshold than the sampler’s own, the span cannot be equalized, so it passes through unchanged. If the incoming threshold is lower, the sampler applies its own threshold: spans whose random number is at or above it are kept and marked with the new threshold, and the rest are dropped. The effect is to bring mixed data to a common keep rate, which makes later analysis simpler.

The proportional sampler

A proportional sampler wants to reduce traffic by a fixed factor regardless of what arrives. It multiplies the incoming keep probability by its own configured probability to compute a new, stricter threshold for each incoming span, and then applies the comparison. If the multiplied probability would fall below the smallest representable one, the span is not kept.

A handful of rules, if followed by every participant, protect both whole traces and trustworthy statistics.

The specification lists general requirements for every stage that touches the sampling threshold. They look dry at first, but each one blocks a specific way things can go wrong. Here they are in plain language.

This is the payoff that makes the recorded threshold so valuable: you can estimate what you did not keep.

The adjusted count of a kept span is one divided by its keep probability. If a span was kept at a probability of one percent, then it stands for roughly one hundred real spans, so its adjusted count is one hundred. If it was kept at fifty percent, its adjusted count is two. To estimate how many requests of some kind happened, you add up the adjusted counts of the kept spans of that kind, rather than counting spans one by one.

Mixed probabilities are fine, as long as they are recorded

A backend might hold spans kept at fifty percent from a quiet service and spans kept at one percent from a very busy one. A naive row count would give the quiet service far too much weight. Summing adjusted counts corrects for this automatically, because each span carries a number that reflects how many others it stands for. That is why the recorded threshold matters even for traces nobody ever opens: it powers the numbers on dashboards.

Turning traces into metrics

Using adjusted counts to derive metrics such as request rates and error rates from sampled spans is sometimes called span-to-metrics. The rules in Chapter 14 exist so that these derived numbers are reliable. If a stage secretly changed its keep rate without updating the threshold, every rate computed afterwards would be quietly wrong.

Real teams do not want a single flat keep rate; they want rules like “keep all errors” and “keep very little of the health check traffic”.

A related OpenTelemetry proposal introduces composite samplers, which combine several smaller sampling rules into one decision. Each rule can be simple, such as “requests to the health endpoint keep at a very low rate” or “requests for checkout keep at a high rate”, and a composition picks the matching rule for each span. The consistent probability building blocks described in this tutorial are the base pieces from which such compositions are assembled.

The key point is the rule from Chapter 14: every rule may choose its own threshold, but none may use the shared random number to decide which rule applies. The category a span belongs to is decided by attributes like the operation name, never by the random number. As long as that holds, rule-based sampling keeps all the benefits of consistency.

Let us follow a single request through a realistic system, step by step, and watch the random number and the threshold at work.

A customer taps the pay button in a mobile app. The request enters through a gateway, moves to an order service, then to a payment service, and finally the finished spans flow through a collector to storage. Assume the gateway keeps ten percent of traces as the root sampler, the order and payment services use parent-based sampling, and the collector applies a further proportional reduction.

sequenceDiagram
    participant G as Gateway
    participant O as Order service
    participant P as Payment service
    participant C as Collector
    participant S as Storage
    G->>G: Make sure random value R exists
    G->>G: Compare R with threshold e666
    G->>O: Call with context carrying th and R
    O->>O: Parent-based: copy the parent decision
    O->>P: Call with the same context
    P->>P: Parent-based: copy the parent decision
    P-->>C: Export kept spans with th
    O-->>C: Export kept spans with th
    G-->>C: Export kept spans with th
    C->>C: Proportional thinning raises th
    C->>S: Forward survivors with updated th
        

Most systems already run some form of ratio sampling, so the practical question is how to move without breaking traces along the way.

Early OpenTelemetry ratio-based samplers were meant to be consistent, but the exact way they turned a trace identifier into a decision was never fully pinned down when those samplers became stable. In practice, different language libraries, and even different versions of the same library, could compute the decision differently for the same identifier. Because of that, the original guidance said to use such a sampler only at the root of a trace, together with a parent-based sampler for everything else.

The modern specification pins down the behaviour and ties it to the W3C Trace Context randomness guarantee. During the transition, the guidance is to keep following the older advice until every tracing library in the system has been upgraded. You can tell that the upgrade is complete when all spans in the system carry the trace random flag. To help, the ratio-based sampler issues a warning the first time it assumes randomness for a context where the flag is not set.

Whenever data travels in a header that outsiders can influence, it is worth asking what a misbehaving sender could do with it.

The trace context travels in headers of ordinary requests. At the edge of your system, where requests come from the public internet or from third parties, those headers are untrusted input. A caller could send a crafted trace state with a chosen random value or a fake threshold. The consequences are mostly about data quality and cost, but they deserve thought.

Also remember that traces may contain sensitive attributes such as user identifiers or request details. Sampling reduces the amount of such data stored, but it is not a privacy control. Sensitive values still need to be scrubbed or avoided in the spans that survive.

A sampling setup that nobody watches will drift, so build a small dashboard that tells you whether it is behaving.

Because the whole benefit of this scheme is trustworthy numbers, the most important monitoring checks compare what the data says with what you expect. Here are the checks that give the most value for the least effort.

Patterns capture what tends to work; anti-patterns capture what tends to hurt, and both are cheaper to learn from a page than from an outage.

Patterns that work

Anti-patterns to avoid

A short checklist is often more useful than a long theory, so here are the habits that separate smooth rollouts from painful ones.

Examples help the ideas settle, so here are four situations that teams commonly meet.

No design is free, so let us weigh what consistent probability sampling gives and what it asks in return.

The comparison shows that these approaches are not enemies. Consistent probability sampling is a solid, cheap baseline. Tail techniques, which can look at the finished trace and favour errors or slowness, can be layered on top, as long as they record the probabilities they apply.

You do not need advanced mathematics to trust this scheme; you only need to see why one comparison gives the right keep rate.

Start with a fact about fair randomness: if a number is chosen uniformly from a range, then every equal-sized slice of the range is equally likely to contain it. Cut the 56-bit range at the threshold. The slice below the line holds a fraction of the range equal to the rejection share, and the slice at or above the line holds the keep share. Since the random value lands in each slice with a probability equal to that slice’s share, the chance of landing in the keep slice is exactly the keep probability. That is the entire proof, and it is why the formula for the threshold uses one minus the keep probability.

Why 56 bits is plenty

Fifty-six bits give roughly seventy-two quadrillion distinct values. Even a keep rate of one in a million leaves tens of billions of values in the keep slice, so the slice is never too narrow to behave like a smooth probability. The specification limits keep probabilities to a range that begins at two raised to the power of minus fifty-six, which is the smallest slice that contains at least a single value.

Rounding and the small gap between target and actual

Because thresholds are written with a limited number of hexadecimal digits, the keep probability that a stored threshold really represents can differ slightly from the one the operator typed. The specification gives helpful examples with four digits of precision. A target of one in ten becomes a stored threshold whose real keep probability is about 0.100006, and its adjusted count is about 9.9994 instead of exactly ten. A target of one in three has a real probability of about 0.333328 and an adjusted count of about 3.00005. These gaps are tiny, but they show why the stored value, not the intended one, should be used when computing counts.

Why powers of two are special

Rates like one half, one quarter and one eighth fit perfectly into binary, so their thresholds are short and exact. An earlier line of thinking about consistent sampling restricted probabilities to powers of two for exactly this reason: it makes the arithmetic simple. The newer approach keeps the same shared-number idea but allows nearly any probability by using a full-width threshold, which removes the awkward restriction without giving up consistency.

Let us put every idea together in one story, using the friendly zero-to-one-hundred ruler so the arithmetic fits in your head.

A food-delivery company has a gateway, an order service and a kitchen service. Ten thousand customers place orders in one hour. The gateway is the root and keeps twenty percent of traces. Remember the ruler: twenty percent kept means a threshold of eighty. The order and kitchen services follow the parent. A collector then applies a proportional reduction to fifty percent of what arrives.

flowchart LR
    A["10,000 orders"] --> B["Gateway keeps R at or above 80: about 2,000"]
    B --> C["Collector keeps R at or above 90: about 1,000"]
    C --> D["Backend: each span counts as 10, estimate 10,000"]
        

Notice what would have gone wrong with independent coin flips. If the collector had flipped a fresh fifty percent coin for each span, a kept order would often have lost its kitchen span or its gateway span, and the three-service story would have been broken for about three quarters of the surviving orders. The shared number is what makes the collector’s reduction remove whole orders instead of random pieces.

Sometimes the thing you care about is bigger than one trace, such as a user session or a batch job, and the shared number can be stretched to cover it.

Most of this tutorial treats one trace as the unit of consistency. But the explicit randomness value is just a number placed in a header by the root sampling decision, and nothing prevents the same number from being given to several different traces on purpose. When that happens, those traces rise and fall together: for any threshold, either all of them are above it or all are below it.

Because the keep rate is a plain number, you can plan budgets with simple multiplication before you change a single setting.

The cost of tracing grows with the amount of data you keep, which is the number of requests multiplied by the number of spans per trace, multiplied by the size of each span, multiplied by the keep rate. Everything except the keep rate is determined by your system. That makes the keep rate the main dial for cost, and consistent sampling makes the dial predictable: cut the rate in half and you cut the kept data roughly in half, without damaging trace completeness.

The numbers in this table are illustrative, not measurements of any real company, but the lesson is real: a handful of percentage points at a large scale means hundreds of millions of spans. Also notice that spans per trace matters as much as the keep rate. A trace that is twice as deep costs twice as much per kept request, so reducing needless spans in the application can be as valuable as lowering the keep rate.

A simple planning routine

A careful rollout plus a small troubleshooting table will save you from most surprises.

How to test without touching production first

Before changing anything in production, run a test environment with synthetic traffic that touches every service. Use a high keep rate to gather plenty of data, then check four properties in turn. First, check completeness: nearly every kept trace should have all its expected spans. Second, check nesting: if you lower the keep rate at one stage, the surviving traces must be a subset of the earlier survivors. Third, check the recorded thresholds: every kept span should carry the threshold you expect at its stage. Fourth, check the totals: the sum of adjusted counts should match the number of synthetic requests you generated.

A cautious rollout order

Symptom and likely cause

Many existing systems already reach consistency another way, by hashing the trace identifier, so it helps to see the similarities and differences.

A very common technique takes the trace identifier, runs it through a hash function, and compares the result with a keep rate. Because every service performs the same calculation on the same identifier, they reach the same answer. That is a consistent scheme, and it works well when every participant uses the same hash function and the same seed. Its weak spot is the word same: different languages, libraries or versions often implement the hash slightly differently, and even a small difference breaks agreement across a system.

The OpenTelemetry approach moves the agreement from the calculation to the data. Instead of every participant needing to run the same hash, they only need to read the same shared number and compare it with a threshold, a trivial operation that every language does identically. The threshold is then written into the trace state, which also gives the final backend the knowledge of the keep probability that a pure hash scheme normally lacks.

A tutorial should be honest about how settled the topic is, so here is where things stand.

The OpenTelemetry specification page on probability sampling carries the status Development, in the specification release numbered 1.61.0 at the time of writing. That label means the mechanism is documented and implemented in places, but its details are still allowed to evolve. Treat the concepts in this tutorial, the shared randomness and the rejection threshold, as the stable core, and check the current specification before depending on a fine detail such as an exact field name or default.

It is a way for every service and collector to decide independently, but in agreement, whether to keep a span, by comparing one shared random number with a personal threshold, and then recording that threshold so the keep probability stays known.

No. The shared random number travels inside the normal trace context, and each sampler needs only its own configuration. There is no coordinator and no extra network call.

Because it measures how much of the number range is rejected. Spans whose random number falls below it are dropped, and spans at or above it are kept.

Either from the last seven bytes of the trace identifier, when the library promises they were generated randomly, or from an explicit random value stored in the OpenTelemetry trace state entry.

Yes. Their decisions nest: whatever the stricter sampler keeps, the more generous one also keeps. They do not produce identical sets, but they never contradict each other.

Lowering it would claim that an earlier stage was more generous than it truly was, which would make estimated counts too small. Raising it honestly records an extra round of thinning.

It means nothing is rejected, so every span is kept. It stands for a keep probability of one hundred percent.

Its keep probability is unknown, so it cannot be used for adjusted counts. It may still be stored and viewed like any other span.

Not by using the shared random number alone, since errors are not known at the start of a request. Rule-based and tail approaches can favour errors, provided they choose their own thresholds and record them honestly.

No. Probability sampling is defined from a tiny positive probability up to one hundred percent. Dropping everything is valid configuration but is not a form of probability sampling and carries no threshold.

No. They complement each other. Consistent probability sampling gives a cheap, correct baseline, and tail techniques can be layered on top for smarter choices.

The specification is marked as in development, and support varies by language and tooling. Many teams adopt the ideas gradually, starting with root-only ratio sampling and parent-based followers, and verify support in their own libraries first.

We began with a courier company whose warehouses flipped private coins and ended up with an album full of fragments. Consistent probability sampling replaces those private coins with one shared lucky number on the parcel label and a personal cut-off line at every warehouse. Because everyone reads the same number, the decisions nest neatly, whole traces survive at the configured rate, and different services can still choose different rates. By recording the threshold that was applied, the system also remembers how many real spans each kept span stands for, so totals, rates and dashboards remain trustworthy even though most data was never stored. The scheme is cheap, needs no coordination, and fits naturally into the headers that already travel with every request, though its specification is still in development and deserves a fresh look before you commit to details.