Skip to Content

Can I send traces from OpenLLMetry to Rius unchanged?

Yes, Rius accepts traces from an app already instrumented with OpenLLMetry: you point the exporter at the Rius endpoint and add an Authorization header, with no re-instrumentation. Rius reads the OpenLLMetry attributes as they are and maps them onto its own keys when the spans arrive. Model, token and cost views then work without changes to your instrumented code. Cost is a list-price estimate in US dollars that Rius computes, so you never send it.

How it works

OpenLLMetry (Traceloop’s SDK) exports OTLP over HTTP with protobuf by default, which is the format the Rius ingest endpoint expects. Rius ingests traces only, over HTTP, with no gRPC endpoint.

When spans arrive, Rius normalizes the several attribute conventions OpenLLMetry has used across versions onto its canonical keys:

  • Current releases already emit OpenTelemetry GenAI attributes (gen_ai.*), which Rius reads directly.
  • Older releases flatten messages into gen_ai.prompt.* and gen_ai.completion.*, spell usage as gen_ai.usage.prompt_tokens and completion_tokens, and mark streaming as llm.is_streaming. Rius maps all of these.
  • The traceloop.span.kind value from the Traceloop decorators (workflow, task, agent, tool) becomes the span type in Rius. The decorated function’s name becomes the tool or agent name.
  • traceloop.entity.input and traceloop.entity.output become the span’s input and output.

Traces arrive with their spans nested, and prompt and completion content is visible when you inspect a trace. Because attributes are stored under their canonical keys, you search and filter on gen_ai.usage.input_tokens rather than gen_ai.usage.prompt_tokens. Rius computes cost on its side from the model and the token counts. The full mapping is in the OpenLLMetry page.

Two things are not mapped yet. The per-completion gen_ai.completion.N.finish_reason of older releases and the flattened tool definitions under llm.request.functions.* are stored under their own names.

Set it up

  1. Create an API key in the console. The key decides which workspace the traces land in.
  2. Change the exporter settings in your Traceloop.init call. Keep your own app_name. The host below is for the eu region, so use the host for your workspace’s region if it differs.
from traceloop.sdk import Traceloop
 
Traceloop.init(
    app_name="my-agent",
    api_endpoint="https://ingest.eu.console.rius-glassflow.com",
    headers={"Authorization": "Bearer <your API key>"},
)

  1. If you prefer configuration over code, OpenLLMetry’s environment variables carry the same values: TRACELOOP_BASE_URL takes the base URL, and TRACELOOP_HEADERS takes the header, with %20 for the space. In Python, remove any old TRACELOOP_BASE_URL and TRACELOOP_HEADERS from your deployment, because they override the Traceloop.init() arguments. Also set TRACELOOP_METRICS_ENABLED to false: Rius ingests traces only, so the Python SDK’s metric exports otherwise fail with a logged 404.

  2. Run one traced LLM call, open Traces in the console, and open the new trace. The LLM span should show a model name and token counts.

  3. If you run long agent runs on an older OpenLLMetry release, raise OpenTelemetry’s per-span attribute limit. Those releases record messages one attribute per field, so a long run can exceed the default of 128 attributes and lose data. The OpenLLMetry page points to the details.

If nothing arrives, a 401 from the endpoint means the API key is wrong or revoked. The Trace LLM calls with OpenTelemetry guide shows this exporter next to the other OpenTelemetry paths, and the Interoperability overview lists every sender guide.

What you might still add

  • session.id and user.id on your spans, root span included. With no session.id, each trace is its own session. With no user.id, the trace counts as anonymous. Prefer an opaque user id to an email.
  • A stable service.name, so your agent is grouped under one name.
  • The Rius SDK, if you later want its extras: message normalization, a raised attribute limit, export-time privacy controls and heartbeats.

What you get

  • Traces from your existing OpenLLMetry setup in the Rius trace list, with nested spans and prompt and completion content.
  • Model, token and cost analytics across OpenLLMetry’s old and new attribute conventions.
  • Span types taken from your Traceloop decorators, with tool and agent names from the decorated function names.
  • Cost per call as a list-price estimate in US dollars. A model Rius does not know gets an empty cost, not zero.
  • No change to the instrumentation in your application code. Only the exporter endpoint and header change, plus the metrics setting in Python.

When something else fits

  • If your code uses Traceloop’s prompts, guardrails, feedback, datasets or experiments, re-pointing breaks them in Python, because Traceloop.get() raises once the base URL is not Traceloop’s. Keep OpenLLMetry pointed at Traceloop and fan out to Rius through a Collector.
  • If you want to keep your current backend while you evaluate Rius, route spans through an OpenTelemetry Collector and fan out to both. The OpenLLMetry page links to that guide.
  • If you have no tracing yet, the Rius SDK sets up the exporter and auto-instruments common LLM libraries with one init() call.
  • Rius does not import historical data from another tool, so only traces sent after you change the exporter appear.

Still stuck? Get help

Last updated on
Quickstart