Radicas Docs
Ingestion

Bring your own Collector

Run your own OpenTelemetry Collector in front of Radicas for fan-out, buffering, or redaction — tenant attribution is unaffected.

Because Radicas ingestion is a standard OTLP endpoint, you do not have to send directly from the agent process. Running your own OpenTelemetry Collector between your agents and Radicas is a first-class, fully supported topology — the same pattern other OTel-native vendors support.

Why run your own Collector

Common, legitimate reasons:

  • Fan-out — send the same telemetry to Radicas and to other backends.
  • Local buffering and retry — survive network blips without losing spans.
  • PII redaction before egress — scrub prompt/response content before it leaves your network.
  • Single firewall egress — one controlled exit point instead of many agent processes.
  • Environment tagging — add deployment attributes centrally.

Exporter configuration

Add an exporter pointing at Radicas and include it in your trace, metric, and log pipelines:

exporters:
  otlphttp/radicas:
    endpoint: https://ingest.radicas.io
    headers:
      authorization: "Bearer ___INGEST_KEY___"   # sign in to see your real key

Sign in to see your real key pre-filled in this snippet. In production, keep the key out of the config file — reference an environment variable instead (${RADICAS_INGEST_KEY} with the Collector's environment-variable substitution).

Tenant attribution is unaffected

The Radicas gateway authenticates the key on the connection to Radicas, not anything inside the payload, so it is agnostic to your upstream topology. Tenant identity is resolved from the validated key and stamped onto every span at the edge with an upsert — an intermediary Collector cannot spoof or misroute radicas.tenant_id, and per-tenant rate limiting applies regardless of how many hops the data took. Details in tenancy and ingestion.

Caveats

  1. Do not strip gen_ai attributes. Relaying and batching are fine, but processors that drop gen_ai.usage.*, gen_ai.request.model, span parent/child links, or radicas.feature break cost computation and per-feature attribution. See the endpoint reference for the full list.
  2. One key = one tenant. All telemetry sent with a given key lands in that key's tenant. To forward multiple Radicas tenants through one Collector deployment (for example as an MSP), configure one exporter per key; per-request key routing through a single pipeline is planned post-MVP.

On this page