How do you make OpenLLMetry send traces to your own backend instead of Traceloop's cloud?

## Destination is a parameter, not a lock-in The most common misconception about OpenLLMetry is that adopting it means adopting Traceloop's SaaS. It does not. The SDK is a packaging of OpenTelemetry instrumentation for LLM libraries, and the exporter — the component that decides where finished spans go — is configurable at `init`. ## Route one: point the built-in exporter elsewhere Out of the box the SDK builds an OTLP exporter. You can retarget it without writing exporter code: - `Traceloop.init(app_name="chat-api", api_endpoint="http://otel-collector:4318", headers={"x-tenant": "eu"})` - or the environment equivalents `TRACELOOP_BASE_URL` and `TRACELOOP_HEADERS`, with `TRACELOOP_API_KEY` for the hosted endpoint. Environment variables are usually the better production choice, because destination is a deployment concern: the same image runs against a local collector in dev and a gateway collector in prod, with no code change and no per-environment branch in your startup path. ## Route two: pass your own exporter object `init` takes an `exporter` argument that accepts any OpenTelemetry span exporter instance. This wins when you need something the endpoint settings cannot express: - an exporter with custom transport, retry or credential behaviour; - a vendor's own exporter implementation; - `ConsoleSpanExporter` for local debugging, which prints each finished span to stdout and answers "is anything being produced at all?" faster than any dashboard; - an in-memory exporter in tests, so a test can assert that a workflow span was emitted with the attributes you expect. When you pass `exporter`, it is the destination — the endpoint settings no longer apply. ## Why teams route to their own collector Sending to a collector you run, rather than straight to a vendor, is the mainstream production pattern for reasons that have little to do with OpenLLMetry specifically: 1. **One trace, one place.** If your web framework and database clients are already OTel-instrumented, the LLM span joins the request's existing trace. "This endpoint got slow" and "this model call got slow" become the same investigation instead of two tools and a timestamp correlation. 2. **Redaction at the boundary.** Prompt and completion text is captured by default, and a collector is a natural chokepoint to scrub or drop attributes before they leave your network. That is a stronger control than trusting every service to configure itself correctly. 3. **Vendor portability.** Changing backends becomes a collector config change rather than a redeploy of every service. 4. **Egress and cost shaping.** Sampling, filtering and batching happen once, centrally, on data that has already left the request path. The detailed design of that collector — receivers, processors, tail sampling, gateway topology — is a separate OpenTelemetry subject; from OpenLLMetry's side the whole integration is "which endpoint, which headers". ## Debugging destination problems When spans do not arrive, split the question in two: *are spans being produced* and *are they arriving*. Swap in a console exporter and rerun; if you see spans in stdout, instrumentation is working and the problem is endpoint, credentials, network or the backend. If you see nothing, the problem is upstream — instrumentation not applied, calls made before `init`, or a process exiting before export. Two destination-specific traps are worth remembering. First, the path and port conventions differ between OTLP over HTTP and OTLP over gRPC, and a wrong endpoint typically fails quietly in the exporter's own logs rather than raising in your application — telemetry systems are built not to take the app down. Second, authentication headers for a vendor backend belong in `headers`/`TRACELOOP_HEADERS`; a missing header usually surfaces as rejected exports on the receiving side rather than as an error you notice locally. ## Interview framing If asked "does using OpenLLMetry mean sending our prompts to a third party?", the strong answer is: no, the destination is `init`'s exporter or endpoint configuration, the common shape is exporting to a collector we run, and content capture is separately controllable. That answer demonstrates you understand OpenLLMetry as an instrumentation library rather than a SaaS client.