Skip to main content
This lesson demonstrates how to apply sampling to reduce the number of traces generated by a service. Sampling helps lower telemetry volume sent to backends while preserving a representative subset for debugging and observability. For demonstration we use the Console exporter so sampled spans are printed directly to application stdout. You can replace it with another exporter (for example, the OTLP exporter) and sampling behavior will remain the same.

Why sampling?

  • Reduces network, storage, and processing costs by exporting fewer traces.
  • Keeps a representative subset of traces for performance and error analysis.
  • Deterministic sampling (based on trace ID) ensures consistent decisions across services that share the same trace context.

Example: TraceIdRatioBased sampler (10%) + Console exporter

Below is a complete example that sets up:
  • a TraceIdRatioBased sampler with 10% sampling,
  • a BatchSpanProcessor,
  • a ConsoleSpanExporter for demo output (with an OTLP exporter commented out if you want to send traces to a collector instead).
The TraceIdRatioBased sampler uses the trace ID to produce a deterministic sampling decision. A ratio of 0.1 will sample approximately 10% of traces; 0.0 samples none and 1.0 samples all.

How to use this in your app

  1. Call configure_tracer() during application startup (before handling incoming requests).
  2. Run your service (for example, a Flask app exposing a /charge endpoint).
  3. Generate requests (e.g., with curl) and watch application stdout for exported spans when requests are sampled.
Example requests:
Because sampling is probabilistic and based on trace IDs, you should see roughly 1 out of 10 requests produce exported trace output when using a TraceIdRatioBased(0.1) sampler.

Sampler options at a glance

SamplerUse caseExample
TraceIdRatioBasedProbabilistic sampling using trace ID for consistent sampling across servicesTraceIdRatioBased(0.1)
AlwaysOnCapture all traces (useful for debugging)AlwaysOn()
AlwaysOffCapture no traces (useful to disable tracing)AlwaysOff()

Resource example

When creating resources, include identifying attributes for your service:
  • Example resource used above: { "service.name": "charge-service", "service.version": "0.5.0" }

Best practices & troubleshooting

  • Use a conservative sampling ratio in production to control telemetry costs; consider higher sampling for error traces or slow requests.
  • If you require guaranteed capture of specific requests (e.g., errors), implement custom sampling logic or use a tail-based sampling approach at the collector.
  • If you switch to OTLP, verify your collector/backend is reachable and the endpoint is correctly configured.
  • Monitor the rate of sampled traces and adjust the ratio if you need more or fewer traces.
Avoid setting TraceIdRatioBased too low in early production or when first instrumenting a service—you may miss important traces. For debugging or initial rollout, start with higher sampling and reduce once you have confidence in coverage and cost.
Using sampling reduces the volume of traces sent to your backend while maintaining a useful subset for observability and debugging. Adjust the sampling strategy to match your telemetry needs and cost constraints.

Watch Video