OpenTelemetry tracing wired up correctly
OpenTelemetry needs a tracer provider, a resource that names your service, an exporter, and a sampler before any spans are produced. This tool generates that bootstrap for Node.js or Python with the exporter and sampling you choose.
How it works
A Resource carries the attributes that identify the producer, the most important being service.name; backends group traces by it, so omitting it leaves spans as unknown_service. The TracerProvider is the factory for tracers and holds the configured sampler and span processors. Sampling uses TraceIdRatioBased, which keeps a deterministic fraction of traces derived from the trace ID — set 1.0 to record everything in development or 0.1 to keep a tenth in production. Because the decision is based on the trace ID, the same trace is sampled consistently across every service it touches.
Finished spans pass through a BatchSpanProcessor, which buffers them and exports in batches instead of one call per span, then out through an exporter. OTLP over HTTP is the vendor-neutral default that talks to the Collector and to backends including Jaeger, while a console exporter prints spans for debugging. Auto-instrumentation patches common libraries as they load, which is why this code must run before the rest of your app — in Node via node -r ./otel.js, in Python via the opentelemetry-instrument launcher.
Tips and example
Send to a Collector rather than directly to a backend so you can re-route or add processing without redeploying. A minimal Node setup:
import { NodeSDK } from "@opentelemetry/sdk-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
import { TraceIdRatioBasedSampler } from "@opentelemetry/sdk-trace-base";
const sdk = new NodeSDK({
traceExporter: new OTLPTraceExporter({ url: "http://localhost:4318/v1/traces" }),
sampler: new TraceIdRatioBasedSampler(0.1),
});
sdk.start();
Keep sampling at 1.0 while you verify spans arrive, then lower it for production once the pipeline is confirmed.