distributed-tracing

Create a TracerProvider with a resource and sampler, add a BatchSpanProcessor with an OTLP exporter, then call FastAPIInstrumentor.instrument_app on your app. Also instrument HTTPX, SQLAlchemy, and Redis so outbound calls and database queries produce child spans automatically.

Use the OpenTelemetry NodeSDK with getNodeAutoInstrumentations, an OTLP trace exporter, and a TraceIdRatioBasedSampler, loading it before any other imports. Auto-instrumentation covers HTTP and PostgreSQL, and you can add custom spans with tracer.startActiveSpan in route handlers.

Both accept OTLP spans from the OpenTelemetry Collector, so you can export to either or both simultaneously. Jaeger provides an all-in-one UI for trace search, while Tempo integrates with Grafana dashboards and uses object storage for lower-cost retention.

Use 100% sampling in dev and staging, and 1-10% for high-traffic production services. Combine this with tail sampling in the collector so 100% of error traces and slow traces above a latency threshold are always captured regardless of the base rate.

Broken traces usually mean context propagation is missing on an outbound call. Every HTTP request, message, or job must inject the W3C traceparent header, and the receiving service must extract it to create child spans under the same trace ID.

No, exclude health and metrics endpoints from instrumentation since they flood the backend with useless spans. Use excluded_urls in FastAPI instrumentation, ignoreIncomingRequestHook in Node.js, or a filter processor in the collector.