Can I send OpenTelemetry metrics and logs to Rius?

Rius takes OpenTelemetry traces only, and it computes cost, tokens, error rate and time to first token from those traces, so you don’t send metrics. Send your agent’s spans over OTLP and read the numbers on the usage and cost views. Your own OTLP metrics and logs stay with the destinations you already use for them.

How it works

Rius ingests traces, not OTLP metrics or logs. The ingest endpoint takes OTLP over HTTP, as http/protobuf (recommended) or http/json. There is no gRPC endpoint.

The numbers you would normally build from metrics come from the spans instead:

• Cost per call. Rius computes it from the model name and token counts on each model-call span, and prices it with LiteLLM’s public model-price catalog in US dollars. These are list-price estimates, not billed amounts. An unknown model gets an empty cost, not zero.
• Time to first token. Rius computes it from the spans, and shows p50 and p95.
• Usage and error rates. Traces, duration, tokens, error rate and cost by model are charted over a window from 15 minutes to 30 days, or a custom range.

You never send a cost or a latency value. Rius derives both from the spans you send.

Because the endpoint is plain OTLP, any sender that can export traces works: the Rius SDKs, vanilla OpenTelemetry SDKs, OpenLLMetry, OpenInference or an OpenTelemetry Collector. The Interoperability section covers each of these paths. Trace LLM calls with OpenTelemetry compares them on one page.

Set it up

1. Point only the trace exporter at Rius. The traces-specific OpenTelemetry variables name the trace signal and nothing else, which suits a process that also exports other signals elsewhere. Use an ingest key that starts with ri_.

   export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://ingest.eu.console.rius-glassflow.com/v1/traces
   export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
   export OTEL_EXPORTER_OTLP_TRACES_HEADERS="Authorization=Bearer%20ri_..."

2. Keep your metrics and logs exporters where they are. Rius does not take them, so leave their endpoints on the destinations you already use.

3. Route with a collector if you want one pipeline. If your telemetry already passes through an OpenTelemetry Collector, the collector can route or fan out the trace pipeline to Rius while the metrics and logs pipelines continue to their current destinations. The collector guide under Interoperability shows how to wire this.

4. Make the spans carry what Rius computes from. Model-call spans need the model name and token counts, using the GenAI attribute names from the attribute reference in the same section. Do not add a cost attribute, because Rius computes cost itself.

5. Open the usage and cost views. Once spans arrive, cost, tokens, error rate and time to first token appear without any metrics setup.

What you get

• Cost, tokens, duration, error rate and time to first token as charts, computed from your traces, with cost by model.
• Custom alerts on the same signals: cost, input, output and reasoning tokens, duration, time to first token, context usage, error rate, LLM error rate, errors, traces and LLM calls. You can filter them by service, agent, step, model, span kind, operation, session or instance.
• Alert delivery to webhook, email or Slack.
• Per-call detail that a counter cannot give you. Each trace shows its own model calls and tool calls, with the cost of each call.
• A clean split of responsibilities. Rius holds agent runs, and your existing metrics and logs backends keep the infrastructure signals.

When something else fits

If you need a place to store OTLP metrics or logs, such as host metrics or application log lines, keep them in the backend you already use, because Rius ingests traces only. If you want one OTLP pipeline for everything, an OpenTelemetry Collector can send traces to Rius and the other signals elsewhere.

Related