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 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.
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 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: