Can I run Rius alongside Traceloop while I migrate?

Yes, Rius runs alongside Traceloop during a migration, and the cleanest way is an OpenTelemetry Collector that sends the same spans to both backends. Both see identical traces, so you compare trace trees, token counts and cost on the same traffic. You turn Traceloop off only after Rius shows what you need.

How it works

Traceloop’s SDK is OpenLLMetry, which is plain OpenTelemetry and exports OTLP to whatever endpoint you give it. That means you do not change your instrumentation to add Rius as a second destination.

• Collector fan-out (recommended). Point OpenLLMetry at a Collector. The Collector holds two otlphttp exporters, one for Traceloop and one for Rius, and lists both in the traces pipeline. Each backend receives the same spans.
• One service at a time. Re-point a single service at Rius while the rest keep reporting to Traceloop. This also works as a staged rollout.
• Not both SDKs in one process. If you later swap OpenLLMetry for the Rius SDK, remove OpenLLMetry in that process. Both instrument the same client libraries, so running them together produces duplicate LLM spans. Run one or the other per process.

The Collector route matters most if you use Traceloop’s platform features from Python. Re-pointing OpenLLMetry’s base URL at Rius switches off get_prompt(), guardrails, user feedback, datasets and experiments, because the platform client is built only when the base URL is Traceloop’s. With a Collector in between, OpenLLMetry keeps its Traceloop settings and Rius is simply added.

Set it up

1. Create a Rius workspace and an API key. The Traceloop migration guide links the quickstart and covers the full cutover.
2. Run an OpenTelemetry Collector and set RIUS_API_KEY and TRACELOOP_API_KEY in its environment. Use the otlphttp exporter for both backends, not otlp, because the plain otlp exporter speaks gRPC and Rius does not accept gRPC. The Collector page covers the exporter details.
3. Add both exporters to one traces pipeline:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
 
processors:
  batch:
 
exporters:
  otlphttp/traceloop:
    endpoint: https://api.traceloop.com
    headers:
      authorization: Bearer ${env:TRACELOOP_API_KEY}
  otlphttp/rius:
    endpoint: https://ingest.eu.console.rius-glassflow.com
    encoding: proto
    compression: gzip
    headers:
      authorization: Bearer ${env:RIUS_API_KEY}
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/traceloop, otlphttp/rius]

4. Set TRACELOOP_BASE_URL in your application to the Collector’s address on port 4318, using an http URL, and send no headers from the application. The Collector adds the keys.
5. In the Python SDK, also set TRACELOOP_METRICS_ENABLED to false, or add a metrics pipeline that exports to Traceloop only. OpenLLMetry’s Python SDK still sends OTLP metrics to the Collector, and the config above has no metrics pipeline. Rius ingests traces only.
6. Send one request and check that both backends show the same trace tree. In Rius, check that the generation shows model and token counts, that cost appears, and that traces with a conversation id share a session.

What you get

• Identical spans in both backends, so the comparison is on real traffic and not on a test run.
• Your decorators (@workflow, @task, @agent, @tool) keep working. Agents and tools appear as agent and tool spans, and workflows and tasks appear as generic steps.
• Cost computed by Rius from the model and token counts, plus sessions from OpenLLMetry’s conversation id.
• A reversible migration. Nothing is cut until you revoke the Traceloop key.

When to turn Traceloop off:

1. Compare both backends on real traffic for a few days: trace counts, token totals and cost.
2. Move anything that reads from Traceloop, such as dashboards, Slack digests and monitors, to Rius equivalents like alerts, or decide to leave them behind.
3. Remove the Traceloop exporter from the Collector.
4. Revoke the Traceloop API key once nothing sends to it and no SDK feature still calls the Traceloop API.

Existing traces stay in Traceloop. Rius starts from the first span you send it.

When something else fits

• If you depend on Traceloop’s monitors, evaluators, guardrails, prompt registry, datasets or experiments, keep Traceloop for those and leave the fan-out running. Rius does not offer them.
• If you want Rius-native session and user scopes or partial spans, swap OpenLLMetry for the Rius SDK in a service and remove OpenLLMetry there. See Migrate to Rius for the other paths.

Related