How do I move my metadata and tags from Arize Phoenix to Rius?

Rius stores Phoenix metadata and tags as span attributes that you can filter by key, so you keep your OpenInference code and re-point the exporter. Rius has no dedicated metadata or tag views. If you need a value to group traces, move it to service.name, session.id or user.id. Existing Phoenix traces stay in Phoenix, and Rius starts from the first span you send.

How it works

Phoenix and Rius both read OpenInference spans, so the metadata and tags your instrumentation sets travel on the spans you already produce. Here is how each Phoenix concept lands in Rius:

• Metadata and tags (using_metadata, using_tags) become span attributes. You can filter by their key. They do not drive grouping, views or analytics, and there are no views built around them.
• Project (project_name, openinference.project.name) becomes the agent, named by service.name. Rius stores the project attribute but does not group by it. If you used separate projects per environment, give each environment its own workspace and API key.
• Session (using_session) becomes a session through the same session.id attribute.
• User (using_user) becomes a user through the same user.id attribute.

This is why a value you used as a tag for slicing is better moved to one of the grouping attributes. Put an environment or team in service.name or the workspace, a conversation in session.id, and a customer in user.id. Rius groups, charts and alerts on those. Everything else stays searchable as a plain attribute.

Set session.id and user.id on every span of the trace, the root span included. The trace list shows a trace under the session and user of its root span. using_session and using_user stamp only spans that OpenInference creates, so a root span from a plain OpenTelemetry tracer misses them.

Set it up

1. Keep your instrumentation and re-point the exporter. Your metadata and tag code does not change. Pass the full traces URL, the protocol and your Rius key, and set service.name so traces do not arrive as unknown_service:

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,
)

2. Move grouping values to the attributes Rius groups by. If you tagged traces with something you want to slice on, set it as the session or user, or set the attributes on your root span yourself:

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

3. Optional: switch to the Rius SDK. If you replace register() with rius.init(), change using_session and using_user to rius.session and rius.user in the same change. The OpenInference context managers do not stamp spans you start with rius.start_as_current_span or @rius.observe, which are usually the root.

import rius
 
rius.init(service_name="my-agent")
 
with rius.session(conversation_id):
    run_agent(message)

4. Run both backends while you check. Add Rius as a second span processor with replace_default_processor=False so Phoenix keeps receiving spans. Then open one traced request in Rius and confirm that the attributes you used as metadata and tags appear on the span and filter by key.

The full walkthrough, including the side-by-side setup and the cutover checklist, is in Migrate from Arize Phoenix.

What you get

• Your metadata and tags arrive on the same spans as span attributes, filterable by key, with no re-instrumentation.
• Session and user grouping through the same session.id and user.id attributes you already use.
• Agent grouping by service.name, with cost computed by Rius from the model and token counts. You send tokens, never cost.
• A clear boundary. Metadata and tags are searchable data, not a dimension that drives views or analytics.

Some Phoenix pieces have no counterpart in Rius. These include annotations and feedback on spans, evals, datasets and experiments, prompt management and the playground, custom model prices, and importing historical Phoenix traces. Rius is a managed service only, so Phoenix self-hosting does not carry over either. The wider picture is in Migrate to Rius.

When something else fits

• If your workflow depends on tags as a first-class dimension with their own views, or on annotations and feedback attached to spans, keep those parts in Phoenix and run both backends side by side.
• If you need to bring old traces across, keep your Phoenix instance or an export of it, because Rius cannot import historical data.

Related