What does the session.id attribute mean in Rius?

Rius reads session.id as a string that groups the traces of one session, such as a conversation or an agent run. Rius reads it on each span, so set it on every span of a trace, not only the root. A span without it falls back to gen_ai.conversation.id, and then to being grouped by its trace id, so a trace with no session value is its own session.

How it works

• What the key holds. A string you choose, the same for every trace that belongs to one conversation or one agent run. With a plain OpenTelemetry sender you choose it. The SDK’s rius.session() can also mint one.
• Which spans carry it. Rius reads the value per span, so every span in the trace should carry it. The Rius SDK scopes stamp it for you. If you send spans from a vanilla OpenTelemetry SDK, a collector or another language, you set it yourself.
• What Rius shows from it. Traces that share a session.id are grouped as one session. Without it, each trace stands alone as its own session.
• Which other names are read. If a span has no session.id, Rius reads gen_ai.conversation.id, the session key of the OpenTelemetry GenAI conventions. Spans that follow those conventions therefore group into sessions without any change. Laminar spans are also covered: Rius normalizes their lmnr.association.properties.session_id onto session.id at ingest. OpenInference already uses session.id, so Rius stores it as sent.
• Which value wins. The fallback order is session.id, then gen_ai.conversation.id, then the trace id. If you send both session.id and gen_ai.conversation.id on a span, Rius uses session.id.

The full attribute list is on the span attribute reference. The cluster overview, Trace LLM calls with OpenTelemetry, shows where sessions fit among the other attributes you send.

Set it up

1. Pick one id per session. Use a conversation id or an agent run id that stays the same across all the traces of that session. An opaque id works well, because it is stored with the span.
2. Set it with the Rius SDK. In Python, use rius.session. In TypeScript, use withSession. Both stamp session.id on the spans inside the scope, so you do not repeat it by hand.
3. Set it for a whole process. With the Rius SDK, if one process serves exactly one session, set RIUS_SESSION_ID before you start it. Every trace from that process then shares the session.

export RIUS_SESSION_ID="support-chat-1234"

4. Set it yourself without the SDK. With a vanilla OpenTelemetry SDK or a collector, add session.id as a string attribute on every span of the trace, root included. If your instrumentation already writes gen_ai.conversation.id, Rius reads that instead when session.id is absent.
5. Pair it with the user, if you have one. user.id works the same way, on every span in scope, and identifies who the request served.

The value above is an example of your own. Replace it with an id from your application.

What you get

• Traces from one conversation or run grouped together as a session, so you read them as one story instead of as separate traces.
• Session grouping without code changes when your spans already carry gen_ai.conversation.id.
• Session grouping for Laminar and OpenInference spans, because Rius reads their session keys.
• A safe default: a trace with no session value is its own session, so nothing is dropped or merged by mistake.
• Session grouping that works for any sender, SDK or not, because the grouping rests on one plain string attribute.

When something else fits

• If your instrumentation already writes gen_ai.conversation.id on every span, you do not need to add session.id as well.
• If you want to group traces by the person they served rather than by conversation, set user.id instead of, or next to, session.id.
• If every request is a standalone call with no follow-up, leave session.id unset and let each trace be its own session.

Related