If your workstations already report OpenTelemetry to a collector you operate, you do not need to touch the workstations to add Torii. Instead, add Torii as a second exporter on the collector. Your existing backend keeps receiving everything it received before; a copy now also lands in Torii.

This article covers six collectors:

• otelcol-contrib (the upstream OpenTelemetry Collector contrib distribution)
• Grafana Alloy
• Datadog Agent
• Splunk OpenTelemetry Collector
• AWS Distro for OpenTelemetry (ADOT)
• Elastic Agent

If you don't already operate one of these, the collector path is not the right starting point - use the MDM rollout path instead and let workstations talk to Torii directly.

The standard 2-step flow

Step 1 - Add Torii as a second exporter

Each collector has a slightly different config format, but the shape is the same:

1. Define a new exporter named otlphttp/torii (or equivalent) pointing at https://ai-events.toriihq.com with a Bearer token from the TORII_INGEST_TOKEN environment variable.
2. Add it to the exporters list of your metrics and logs pipelines alongside your existing exporter(s).

Step 2 - Set the ingest token in the collector's environment

Export TORII_INGEST_TOKEN from a secret store (Vault, AWS Secrets Manager, a Kubernetes Secret, etc.) and inject it into the collector process. Reload the collector. Do not paste the token directly into the YAML - keep it in environment-injected secret material so rotation only touches one place.

Then run a test event from a workstation to validate the new exporter is receiving traffic.

otelcol-contrib (also: Splunk OTel, ADOT - same shape)

Add to your existing collector config:

exporters:
  # ... your existing exporters ...

  otlphttp/torii:
    endpoint: https://ai-events.toriihq.com
    headers:
      Authorization: Bearer ${env:TORII_INGEST_TOKEN}
    compression: gzip

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [<your-existing-exporter>, otlphttp/torii]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [<your-existing-exporter>, otlphttp/torii]

Splunk OTel and ADOT are upstream otelcol with extras - the recipe above is identical. For Splunk, add otlphttp/torii alongside your existing signalfx (metrics) and splunk_hec (logs) exporters. For ADOT, alongside awsemf (metrics) and awscloudwatchlogs (logs).

Grafana Alloy

Alloy uses its own .alloy DSL rather than YAML:

otelcol.exporter.otlphttp "torii" {
  client {
    endpoint = "https://ai-events.toriihq.com"
    headers  = { "Authorization" = "Bearer " + sys.env("TORII_INGEST_TOKEN") }
  }
}

otelcol.processor.batch "to_torii" {
  output {
    metrics = [otelcol.exporter.otlphttp.torii.input]
    logs    = [otelcol.exporter.otlphttp.torii.input]
  }
}

Wire otelcol.processor.batch.to_torii.input into the same receiver outputs that feed your existing Grafana / Mimir / Loki exporters.

Datadog Agent - use a gateway

The Datadog Agent's additional_endpoints setting is DD-protocol-only and does not fan out OTLP. Don't try to use it for Torii.

Instead, put a small otelcol gateway in front of the Agent. The gateway exports to Datadog and Torii in parallel:

Clients --> otelcol gateway --> Datadog Agent (existing) + Torii (new)

Gateway config:

exporters:
  datadog:
    api:
      key: ${env:DD_API_KEY}

  otlphttp/torii:
    endpoint: https://ai-events.toriihq.com
    headers:
      Authorization: Bearer ${env:TORII_INGEST_TOKEN}
    compression: gzip

service:
  pipelines:
    metrics: { receivers: [otlp], processors: [batch], exporters: [datadog, otlphttp/torii] }
    logs:    { receivers: [otlp], processors: [batch], exporters: [datadog, otlphttp/torii] }

Point your workstations at the gateway. The gateway forwards a copy to your Datadog Agent (or directly to Datadog) and a copy to Torii.

Elastic Agent - use a gateway

Elastic Agent's OTel pipeline doesn't expose multi-exporter fan-out cleanly. Same pattern as Datadog: a small otelcol gateway in front.

Clients --> otelcol gateway --> Elastic APM Server (existing) + Torii (new)

Gateway config:

exporters:
  elasticsearch:
    endpoints: ["https://your-elastic.example.com:9200"]

  otlphttp/torii:
    endpoint: https://ai-events.toriihq.com
    headers:
      Authorization: Bearer ${env:TORII_INGEST_TOKEN}
    compression: gzip

service:
  pipelines:
    metrics: { receivers: [otlp], processors: [batch], exporters: [elasticsearch, otlphttp/torii] }
    logs:    { receivers: [otlp], processors: [batch], exporters: [elasticsearch, otlphttp/torii] }

What happens when you push to the collector

After you reload the collector with the new exporter:

1. The next workstation session is captured by your collector as before.
2. The collector's pipeline now fans out the OTLP signals to both your existing backend and to https://ai-events.toriihq.com.
3. Torii's ingest validates the Bearer token, parses the signals, and renders them on the AI Telemetry page.

You should see events appear in the AI Telemetry event tail within a few seconds. If you do not, see Troubleshooting.

Token rotation on the collector path

When you rotate the ingest token in Torii (see Rotating your LLM token tracking):

1. Update TORII_INGEST_TOKEN in the collector's secret store.
2. Restart or signal the collector to pick up the new env var. The previous token stays valid for 24 hours so you have a comfortable window.

If you run multiple collector instances (gateways across regions, sidecars, etc.), update each one. The token validation happens per-request at Torii's ingest, so partial rollouts are fine - instances that still have the old token continue to work for 24h, and you can confirm new-token success by tailing events from a workstation routed through an updated instance.

Next steps

• Verify your setup - send a test event
• Rotating your ingest token
• Troubleshooting and FAQ