Does Rius accept OTLP over gRPC?

No, Rius does not accept OTLP over gRPC, because its ingest endpoint takes OTLP over HTTP only. You send traces as http/protobuf (recommended) or http/json to https://ingest.eu.console.rius-glassflow.com/v1/traces. If your exporter speaks gRPC, put an OpenTelemetry Collector in between: it receives your spans and forwards them to Rius over HTTP.

How it works

• One protocol. Rius ingests OTLP over HTTP. The body is http/protobuf or http/json, and there is no gRPC endpoint.
• Request details. gzip is accepted, the body limit is 16 MiB, and your API key goes in an Authorization Bearer header.
• Traces only. Rius ingests traces, not OTLP metrics or logs.
• The Collector bridges the gap. Your application keeps its gRPC exporter and sends to the Collector. The Collector’s otlphttp exporter sends the spans on to Rius. It appends /v1/traces itself, so you give it the base URL.
• Pick the right exporter. Use otlphttp, not otlp. The plain otlp exporter speaks gRPC, which the Rius endpoint does not accept.
• Spans pass through unchanged. The Collector forwards what your applications emit, so what Rius shows depends on the attributes on those spans, as if you exported directly. For the full list of sender paths, see Trace LLM calls with OpenTelemetry.

Set it up

1. Create an API key in the Rius console and keep it in an environment variable on the machine that runs the Collector, for example export RIUS_API_KEY=ri_....

2. Add an HTTP exporter to the Collector. The otlp receiver takes your application’s spans over gRPC, and the otlphttp exporter forwards them to Rius:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch: {}
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}
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/glassflow]

3. Keep the key out of the file. The ${env:RIUS_API_KEY} substitution reads it from the environment, so the config never holds the secret.

4. Point your application at the Collector. Leave its gRPC exporter as it is and set its endpoint to your Collector instead of Rius.

5. Send a trace and check the console. If analytics fields such as model or tokens come up empty, check that no Collector processor, such as attributes or transform, strips the gen_ai.* keys.

If you can change the exporter and have no need for a Collector, skip it and send HTTP straight from the application. Switch to your SDK’s OTLP/HTTP exporter package, because the protocol variable alone switches only the zero-code agents, Java autoconfiguration and .NET. Register it with no endpoint or headers in code, and set:

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_..."

The Collector guide covers the exporter in full, and the interoperability overview lists every other way to send traces without the Rius SDK.

What you get

• Traces from a gRPC-only exporter reach Rius without changing your application code.
• A single egress point with local buffering, because the Collector sits between your apps and Rius.
• Optional fan-out. Add a second exporter to the same pipeline, for example exporters: [otlphttp/glassflow, otlphttp/existing], and the same traces go to Rius and to another backend.
• The same analytics as a direct export: the trace list, cost per call and the other views read the attributes your spans carry.

When something else fits

• If your language SDK already lets you choose an HTTP exporter, send directly with http/protobuf and skip the Collector.
• If you use Python or TypeScript, the Rius SDK handles the endpoint and protocol for you, so there is no exporter to configure.

Related