OTEL Collector
The OpenTelemetry Collector acts as an intermediate processing layer between your applications and Arize. It collects, processes, and routes telemetry data — useful for centralized credential management, data masking, multi-backend routing, and compliance.
Deployment Models
| Model | How it works | Best for |
|---|---|---|
| Agent mode | Collector runs alongside the app (sidecar or daemonset) | Simple setups, clear 1:1 mapping |
| Gateway mode | Centralized collector receives from multiple apps | Centralized policy, credential management |
| Hybrid | Agent collectors forward to a gateway | Large environments, distributed collection + centralized processing |
Example Configuration
Dynamic Trace Routing
Route traces to different Arize AX projects based on span attributes:Dynamic routing configuration
Dynamic routing configuration

Alternative for Centralized Gateway Collectors
If you operate a centralized collector that serves many teams, you may not want to redeploy the collector every time a new Arize space is added. In that setup, have each application send the targetarize-space-id as request metadata to the collector, then configure the collector to forward that metadata as an outbound header to Arize AX.
This pattern works well when:
- The collector is shared across many teams
- Teams are responsible for selecting their own target Arize space
- You want to avoid maintaining a separate
headers_setterinstance for every space
include_metadata: true; otherwise, the inbound request headers will not be available to the headers_setter extension.
openinference.project.name, so traces continue to land in the expected Arize AX project. This approach is best suited for trusted internal environments where the collector is allowed to honor caller-provided routing metadata.
Beyond centralized routing, you may also need to handle tracing context across async boundaries and services:
Manual Context Propagation
OpenTelemetry handles context propagation automatically in most cases. For async workflows or custom concurrency, you may need to do it manually.Async Functions
Multi-Service Propagation
Propagate tracing context across HTTP calls between microservices: Service A (sends request):ThreadPoolExecutor
Preserve tracing context when submitting tasks to a thread pool:Custom Sampling
Control which spans get recorded to manage telemetry volume and cost:Inheriting Context Attributes in Manual Spans
Context attributes fromusing_session, using_metadata, etc. are NOT automatically attached to manually created spans. Use this helper to pull them in: