Use this file to discover all available pages before exploring further.
Instrument at scale. These patterns are for production systems — routing through an OTEL Collector for centralized processing, propagating context across services and async boundaries, sampling to control volume and cost, and resilient deployment patterns.
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.
Try in-app routing first. For most teams, Route Spans to Multiple Projects using register_with_routing from arize-otel is enough — no collector to operate, no extra infrastructure. Only reach for the collector pattern below if you need centralized policy or routing logic the SDK can’t express.
Route traces to different Arize AX projects based on span attributes:
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 target arize-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_setter instance for every space
When using this approach, make sure the OTLP receiver is configured with include_metadata: true; otherwise, the inbound request headers will not be available to the headers_setter extension.
Applications should still set the project name as a resource attribute, for example 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:
from flask import Flask, requestfrom opentelemetry import trace, propagateapp = Flask(__name__)tracer = trace.get_tracer(__name__)@app.route("/endpoint")def endpoint(): context = propagate.extract(dict(request.headers)) with tracer.start_as_current_span("service_b_processing", context=context) as span: span.add_event("Received request in service B") return "Hello from Service B"
Context attributes from using_session, using_metadata, etc. are NOT automatically attached to manually created spans. Use this helper to pull them in:
from openinference.instrumentation import get_attributes_from_contextdef create_span_with_context(tracer, name, **kwargs): with tracer.start_as_current_span(name, **kwargs) as span: context_attributes = dict(get_attributes_from_context()) span.set_attributes(context_attributes) return span# Usagewith using_session("my-session-id"): with create_span_with_context(tracer, "my-manual-span") as span: # span now has session.id attached ...