Can I run Rius alongside Arize Phoenix while I migrate?

Yes, Rius runs alongside Arize Phoenix, so you can send the same traces to both while you evaluate. Add Rius as a second span processor on your existing tracer provider, or add one more exporter to your OpenTelemetry Collector. Both backends receive identical spans, and you remove the Phoenix exporter only when Rius shows what you need.

How it works

Phoenix and Rius both read OpenInference spans over OTLP with a Bearer token, so your instrumentation stays as it is. You change only where spans go. There are two ways to send them to both backends:

• Two exporters in your code. Keep register() pointed at Phoenix and add a second span processor that exports to Rius on the same provider. Pass replace_default_processor=False. Without it, the provider removes its Phoenix exporter when you add a processor, and your Phoenix project goes quiet.
• Fan-out in a Collector. If your applications already export through an OpenTelemetry Collector, add one more otlphttp exporter to the traces pipeline. Your applications do not change. See the OpenTelemetry Collector page for the full configuration.

Because both backends see the same spans, you can compare trace trees, token counts and cost on the same traffic. The setup is reversible until you remove the Phoenix exporter.

Set it up

1. Create a Rius workspace and an API key, then export it as RIUS_API_KEY. A new organization starts on a trial of 30 days or 500,000 spans, whichever comes first, with no card. Plan your comparison to fit inside it, because after the trial without a plan Rius refuses ingest.

2. Option A: add Rius as a second span processor. Your Phoenix settings (PHOENIX_COLLECTOR_ENDPOINT, PHOENIX_API_KEY) stay as they are today.

import os
 
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from phoenix.otel import register
 
# Phoenix, configured as today (PHOENIX_COLLECTOR_ENDPOINT, PHOENIX_API_KEY)
tracer_provider = register(
    project_name="my-agent",
    batch=True,
    resource=Resource.create({"service.name": "my-agent"}),
    auto_instrument=True,
)
 
# Rius, as a second exporter
tracer_provider.add_span_processor(
    BatchSpanProcessor(
        OTLPSpanExporter(
            endpoint="https://ingest.eu.console.rius-glassflow.com/v1/traces",
            headers={"Authorization": f"Bearer {os.environ['RIUS_API_KEY']}"},
        )
    ),
    replace_default_processor=False,
)

3. Option B: fan out in the Collector. Define the Rius exporter with the base URL, since the otlphttp exporter appends /v1/traces itself, then list it next to your existing one. Use otlphttp, not otlp, because the plain otlp exporter speaks gRPC and the Rius endpoint does not accept it.

exporters:
  otlphttp/glassflow:
    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/glassflow, otlphttp/existing]

4. Set service.name on every service. Rius groups traces by it, and without it they arrive as unknown_service. The Phoenix project attribute is stored but does not drive grouping.

5. If you are not on the Rius SDK, raise the span attribute limit with OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT=4096. OpenTelemetry keeps 128 attributes per span by default, so a long agent loop can lose the model, usage or output on later turns.

6. Set session.id and user.id on the root span too. using_session and using_user only stamp spans created by OpenInference, so a root span from a plain OpenTelemetry tracer shows up as a single-trace session with no user.

The Migrate from Arize Phoenix guide covers these steps and the Rius SDK alternative in full.

What you get

• The same traffic in both tools, so you judge Rius on your own traces before you commit.
• A comparison you can check: trace counts, token totals and cost on identical spans, over a few days of real traffic.
• Cost computed by Rius from the model and token counts, as a list-price estimate in US dollars. You send tokens, never cost.
• A safe way back. Phoenix keeps receiving spans until you remove its exporter, so you can stop at any point.

When to turn Phoenix off. Switch it off when all of these hold:

1. One traced request looks right in Rius: the trace tree, the model call shown with model and token counts, cost, and the expected session and user.
2. A few days of real traffic match between the two backends.
3. Anything that reads from Phoenix, such as dashboards, eval jobs or internal tools, has moved to its Rius equivalent or is deliberately staying in Phoenix.

Then remove the Phoenix exporter, uninstall arize-phoenix-otel if nothing else uses it, and revoke the Phoenix API key once nothing sends to it. The wider Migrate to Rius guide has the same pattern for other tools.

When something else fits

• If you rely on evals, datasets, experiments, annotations or a prompt playground, keep Phoenix for those. Rius does not offer them, so stay on the side-by-side setup instead of cutting over completely.
• Existing Phoenix traces stay in Phoenix. Rius starts from the first span you send it and has no import of historical data.
• If you already route through a Collector, fan out there rather than changing application code.

Related