Workflow: trace sampling as a strategy

# Workflow: trace sampling as a strategy

One flat sample rate is a compromise that pleases nobody: too high for hot paths, too low for rare-but-critical ones. Sample by value instead.

## The principles

1. Errors are always full fidelity. Sampling applies to transactions/traces, never to error events.
2. Sample hot low-value traffic near zero: health checks, static assets, polling endpoints.
3. Sample rare high-value traffic at 1.0: checkout, payment webhooks, admin actions.
4. Keep one baseline rate (0.05-0.2) for everything else so dashboards stay representative.

## Implement with the sampler

```python
def traces_sampler(sampling_context):
    route = sampling_context.get("transaction_context", {}).get("name", "")
    if route.startswith("GET /health"): return 0.0
    if "/checkout" in route or "/webhooks/" in route: return 1.0
    return 0.1
```

The sampler runs per transaction, so decisions follow the request. Keep it pure and fast: no I/O, no database calls.

## Mind the edges

- `traces_sample_rate=0` still continues incoming distributed traces; `None` disables tracing entirely. Use 0, not None, on services that sit mid-trace.
- Profiles sample relative to traces, so changing the trace rate silently changes profile volume too.
- Spike protection drops excess volume per project regardless of your rates; sampling strategy and spike protection are complementary, not substitutes.

## Verify

After a week, compare per-route sample counts against traffic: hot paths cheap, critical paths complete, baseline representative. Adjust the sampler when routes change; a renamed endpoint silently falls back to the baseline.