How do I move my sessions from Traceloop to Rius?

Rius reads the conversation id that OpenLLMetry already writes as a session, so your Traceloop conversations become Rius sessions once you point the exporter at Rius. You keep your @conversation, set_conversation_id and withConversation code as it is. Only the export settings change. Sessions you built from association properties such as chat_id need one extra step, and past sessions stay in Traceloop.

How it works

Traceloop’s SDK is OpenLLMetry, which is plain OpenTelemetry. Here is how each session concept maps to Rius:

• Conversation to session. @conversation, set_conversation_id() and withConversation() stamp gen_ai.conversation.id on every span in scope. Rius groups traces into one session by that id.
• Root span decides the session. Rius lists each trace under the session of its root span, the top-level span of the trace. Set the conversation id before that span starts. In TypeScript, withConversation() also adds a root workflow span.
• Association properties are not sessions. chat_id, user_id and similar properties arrive as traceloop.association.properties.<key> attributes. You can see and filter on them in trace inspection, but Rius does not read them as a session or a user. If you grouped chats by chat_id alone, pass that value to set_conversation_id() or withConversation() instead.
• No session id. A trace with no session id is its own session.

If you swap OpenLLMetry for the Rius SDK, the mapping is with rius.session(cid): in Python and withSession in TypeScript. Remove OpenLLMetry in that case, because running both produces duplicate LLM spans.

Set it up

1. Keep your conversation code. Leave @conversation, set_conversation_id() or withConversation() where they are. Check that each one runs before the outermost span of the request starts, so the root span carries the id.

2. Re-point the exporter at Rius. Create a Rius workspace and API key, then replace the Traceloop settings:

   # Before: Traceloop
   export TRACELOOP_API_KEY="<your Traceloop API key>"
    
   # After: Rius
   export TRACELOOP_BASE_URL="https://ingest.eu.console.rius-glassflow.com"
   export TRACELOOP_HEADERS="Authorization=Bearer%20<your Rius API key>"
   export TRACELOOP_METRICS_ENABLED="false"   # Python SDK only, see below

   Remove TRACELOOP_API_KEY from your deployment. In Python, leftover TRACELOOP_BASE_URL and TRACELOOP_HEADERS values override the arguments to Traceloop.init(), so clear old ones. TRACELOOP_METRICS_ENABLED=false stops the Python SDK from sending OTLP metrics, which Rius does not ingest. The full path is in Migrate from Traceloop to Rius.

3. Replace chat_id grouping if you used it. Where you relied on an association property to group a chat, set the conversation id to the same value so those traces share a session.

4. Optional: move to the Rius SDK. Wrap the call that starts the trace in the session scope:

   import rius
    
   rius.init(service_name="trip-planner")  # reads RIUS_API_KEY
    
   with rius.session(cid):
       weather_agent("Lisbon")

   Here cid and weather_agent are your own names. To put a whole process in one session, set RIUS_SESSION_ID instead.

5. Verify. Send one traced request and open it in Rius. Traces that share a conversation id should appear under one session.

What you get

• Traces that share a conversation id are grouped into one session in Rius, with no change to your instrumentation.
• Each trace is listed under the session of its root span, so a conversation reads as one thread of traces.
• Model, token counts and cost sit on the span for each model call, and Rius computes cost on its side. Costs are list-price estimates in US dollars.
• Your association properties stay as attributes you can inspect and filter on.
• You can run Traceloop and Rius side by side through an OpenTelemetry Collector while you compare, as the Traceloop migration guide describes.

Some things have no counterpart:

• Past sessions stay in Traceloop. Rius starts from the first span you send it.
• Association properties are not turned into sessions or users.
• Traceloop’s platform features, such as monitors, evaluators, datasets and prompt registry, are not offered in Rius.

When something else fits

• If you need your history of sessions, keep Traceloop for that and send new traces to both backends through a Collector.
• If your Python code calls Traceloop platform features such as get_prompt(), re-pointing OpenLLMetry at Rius switches them off, so keep OpenLLMetry pointed at Traceloop and add Rius through the Collector fan-out.
• If you want Rius-native session and user scopes, move to the Rius SDK and drop OpenLLMetry in the same process.

Related