The previous four pages — Resource, Exporter, Span Processor, and Tracer Provider — walked through the OpenTelemetry tracing components one by one. Wiring them up by hand in every application is verbose. TheDocumentation Index
Fetch the complete documentation index at: https://arize-ax.mintlify.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
arize.otel SDK collapses all of it into a single function call — and adds a few OpenInference-specific capabilities on top.
For the practical how-to of installing and using these helpers, see Set up tracing. This page covers what they do under the hood.
Appreciate the Simplicity
Configuring tracing with raw OpenTelemetry — Resource, Exporter, Span Processor, Tracer Provider — looks like this:register() helper replaces all of that:
What register() Does Under the Hood
The convenience function handles four things for you. Each one has additional capabilities specific to OpenInference and Arize AX compared to the standard OTel SDK:
Component returned by register() | What it adds beyond standard OTel |
|---|---|
| Tracer Provider | Returns a provider that hands out OITracer instances — a subclass of the OTel Tracer that reads OpenInference attributes from the OTel context. This is what makes the OpenInference context managers (using_session, using_user, using_metadata, etc.) actually attach attributes to spans. |
| Span Processor | Configured and pre-attached, ready to forward spans to the Arize AX–specific exporter. |
| Span Exporter | Adds the headers needed to authenticate against the Arize AX collector and handles gRPC/HTTP transport correctly for your endpoint. |
| Resource | Sets the project name automatically from your project_name argument. |
ArizeRoutingProcessor and Multi-Project Routing
Setting the project name at the Resource level means all traces from one application go to the same Arize AX project. That’s the right default for most apps. But more complex use cases need to send traces to different projects (or different Arize AX spaces entirely) based on span attributes or request metadata — for example, a multi-tenant app that wants each customer’s traces to land in their own project. The previous workarounds were:- Spin up multiple Tracer Providers — but only one can be the global, so this gets awkward.
- Modify resource attributes at the Collector level with a transform processor — works, but adds operational complexity.
ArizeRoutingProcessor plus the register_with_routing and set_routing_context helpers.
How Routing Works
Arize AX supports overriding the resource-level project name with a span attribute —arize.project.name. The ArizeRoutingProcessor also supports routing across Arize AX spaces via the arize.space_id span attribute.
set_routing_context is a context manager that attaches both attributes to the OTel context, so you don’t have to set them manually on every span.
Configuring Routing
set_routing_context block is routed to the specified space and project.
register_with_routing uses ARIZE_API_KEY from the environment if api_key isn’t passed. Both space_id and project_name must be set inside set_routing_context — otherwise routing won’t be applied.Python-only today. For JS/TS or Go apps — or routing logic the SDK can’t express — route at the OTel Collector layer instead.When to Use Which
| Use case | Recommended approach |
|---|---|
| Single project, simple app | register(...) |
| Multiple projects from one app, per-request routing | register_with_routing(...) + set_routing_context(...) |
| Routing across many spaces in a shared-collector environment | OTel Collector with dynamic routing — see Advanced Patterns |
| Maximum control, custom processor pipeline | Raw OTel — see Configure your tracer |