Can I keep my OpenTelemetry instrumentation when I leave Arize Phoenix?

Yes, Rius reads OpenInference spans, so the OpenTelemetry instrumentation you run for Arize Phoenix stays and you only re-point its exporter at Rius. Your OpenInference instrumentors keep producing the same spans. You change the endpoint, the API key and a service name. Rius then reads models, token counts, sessions and users from those spans and computes cost itself.

How it works

Phoenix is built on OpenTelemetry and OpenInference, and Rius understands OpenInference spans. Migrating is a routing change, not a re-instrumentation.

What can stay

• The OpenInference instrumentors you already run, such as the OpenAI one.
• Your own OpenTelemetry TracerProvider and its span processors.
• phoenix.otel.register(), as long as you pass the Rius endpoint, protocol and key in code.
• The using_session, using_user and using_attributes context managers from openinference-instrumentation. They stamp session.id and user.id, which Rius reads directly.

What changes

• The destination: Rius takes OTLP over HTTP (protobuf or JSON), not gRPC.
• The key, sent as a Bearer token.
• A service.name, because Rius names an agent after it.

What Rius reads from those spans

• openinference.span.kind: AGENT, LLM, TOOL, CHAIN, RETRIEVER, EMBEDDING and RERANKER are read as they are.
• Model call spans with llm.model_name and llm.token_count.* become generations, so each gets model, token and cost analytics.
• session.id and user.id group traces into sessions and users.
• service.name groups traces under an agent.
• Metadata and tags are stored as span attributes and can be filtered by key. They have no dedicated views.
• openinference.project.name is stored but does not drive grouping. If you used a Phoenix project per environment, give each environment its own workspace and API key.

You send tokens, never cost. Rius computes cost from the model and token counts, as a list-price estimate in US dollars.

Set it up

1. Create a Rius API key in the console. The ingest endpoint is https://ingest.eu.console.rius-glassflow.com/v1/traces.

2. If you use register(), pass the endpoint, protocol and key in code:

import os
 
from opentelemetry.sdk.resources import Resource
from phoenix.otel import register
 
tracer_provider = register(
    endpoint="https://ingest.eu.console.rius-glassflow.com/v1/traces",
    protocol="http/protobuf",
    api_key=os.environ["RIUS_API_KEY"],
    batch=True,
    resource=Resource.create({"service.name": "my-agent"}),
    auto_instrument=True,
)

3. Check three details. Setting only PHOENIX_COLLECTOR_ENDPOINT to the Rius URL sends spans to the wrong port, so pass endpoint and protocol in code. Without a service.name, traces arrive as unknown_service. Use batch=True in production, because register() defaults to a synchronous processor.

4. If you build a plain TracerProvider instead, use a standard OTLP/HTTP exporter with the same endpoint and an Authorization Bearer header. Raise the span attribute limit with OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT=4096 or SpanLimits. OpenInference writes one attribute per message and tool field, and OpenTelemetry keeps 128 per span by default, so a long agent loop can lose the model, usage or output on later turns.

5. Put session.id and user.id on the root span too, the top-level span of the trace. The trace list shows a trace under the session and user of its root span. using_session and using_user only stamp spans that OpenInference creates, so a root span from a plain OpenTelemetry tracer misses them. Start the root from the tracer you get from the register() provider, or set the attributes yourself:

with tracer.start_as_current_span(
    "handle-turn",
    attributes={"session.id": conversation_id, "user.id": user_id},
):
    run_agent(message)

6. To compare during evaluation, add Rius as a second span processor on the provider and pass replace_default_processor=False, so the Phoenix exporter stays. The Migrate from Arize Phoenix guide has the full side-by-side code and a cutover checklist.

What you get

• The same OpenInference spans you send Phoenix, now arriving in Rius with the trace tree intact.
• Generations with model, token counts and server-side cost, with no code changes to the instrumentors.
• Sessions and users from the session.id and user.id attributes you already set.
• Both backends receiving identical spans while you compare trace counts, token totals and cost, and a reversible migration until you remove the Phoenix exporter.
• Nothing to host, because Rius is a managed service.

The Interoperability section covers the other ways to send OpenTelemetry traces to Rius. The Migrate to Rius page covers other tools.

When something else fits

• Rius does not offer evals, datasets, experiments, prompt management, annotations or custom model prices. If you depend on them, keep Phoenix for those workflows and run both side by side.
• Existing Phoenix traces do not move over. Rius starts from the first span you send it, so keep your Phoenix history for as long as you need it.
• Rius is a managed service only, so if you need to run the backend yourself, it does not fit.

Related