Can I send my agent traces to Rius and another backend at the same time?

Yes, Rius works alongside another backend when you route traces through an OpenTelemetry Collector. The collector takes in your agent’s spans once and exports the same spans to Rius and to your other backend. Adding Rius is one extra entry in the exporters list, with no application changes.

How it works

The collector sits between your agents and your backends and does the fan-out.

• One receiver. Your agents send OTLP spans to the collector, as they would to any single backend.
• One pipeline, two exporters. The traces pipeline lists both exporters, so every batch of spans goes to each destination.
• Spans pass through unchanged. The collector forwards the spans as your applications emit them. Rius reads the same span attributes as it would if the application exported directly, and your other backend gets the same data.
• Rius over HTTP. Use the otlphttp exporter, not otlp. The plain otlp exporter speaks gRPC, which the Rius endpoint does not accept. The otlphttp exporter appends /v1/traces itself, so you give it the base URL only.

The processors list is shared by the pipeline. A processor that renames or drops attributes, such as attributes or transform, changes the spans before they reach either exporter. If cost or other analytics fields come up empty in Rius, check that the collector is not stripping gen_ai.* keys.

Set it up

1. Add an exporter for Rius to your collector config. Keep the key out of the file by reading it from the environment as RIUS_API_KEY. Rius keys start with ri_.

exporters:
  otlphttp/glassflow:
    endpoint: https://ingest.eu.console.rius-glassflow.com
    # proto is the default encoding and the recommended one; json works too
    encoding: proto
    compression: gzip
    headers:
      authorization: Bearer ${env:RIUS_API_KEY}

2. Keep the exporter you already have for your other backend. In this example it is named otlphttp/existing. Define it with that backend’s own endpoint and credentials.

3. List both exporters in the traces pipeline:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/glassflow, otlphttp/existing]

4. Restart the collector. Your applications keep exporting to the collector and need no change.

The OpenTelemetry Collector page has the full exporter reference. For the wider picture of sending traces to Rius, see Trace LLM calls with OpenTelemetry.

What you get

• The same traces in both places. Each backend receives every span the collector forwards, so you can run Rius next to an existing backend and compare them on identical data.
• Rius analytics from the spans. Rius computes cost and time to first token from the spans, so you never send a cost or latency value. Costs are list-price estimates in US dollars.
• A single egress point. Your applications talk only to the collector, which also buffers locally and holds the Rius key, so the key does not live in application code.
• Traces only. Rius ingests traces, not OTLP metrics or logs. If your collector also carries metrics or logs, send those to your other backend.
• Compressed, size-limited requests. The Rius endpoint accepts gzip, and the request body limit is 16 MiB.

What the other backend does with the spans is up to that backend. Rius only controls what it does with its own copy.

When something else fits

If you have a single destination and one application, you can skip the collector and export straight to Rius from the Rius SDK or any OpenTelemetry SDK. Use the collector when you want fan-out, local buffering or one egress point. Your applications must still emit the span attributes you want analysed, so check what they send before blaming the collector.

Related