Skip to main content
Take full control of OpenTelemetry. The getting started pages cover register() and OpenInference integrations — this page is for when you need more: batch processing for production, routing spans to multiple projects, or configuring resource attributes directly via the OpenTelemetry SDK.

OpenInference Instrumentation Packages

OpenInference provides auto-instrumentors for popular frameworks. Install the package for your provider and attach it once — .instrument() in Python, registerInstrumentations({...}) / package-specific setup in JS/TS, or option.WithMiddleware(...) on the SDK client in Go — and every call is traced automatically.

Set up your tracer

The quickest setup is a single helper that creates an OpenTelemetry TracerProvider wired to Arize AX, attaches the span exporter, and sets it as the global provider. Each SDK reads your space, API key, and project from the environment, so the minimal call needs no explicit credentials. For the full Python SDK reference, see OpenTelemetry Tracing.
arize-otel’s register() returns a TracerProvider you hand to each OpenInference instrumentor’s .instrument(tracer_provider=...) call. All parameters are keyword-only:
These helpers cover most apps — but when you need more control over the tracer itself, configure OpenTelemetry directly:

Configure the OTel Tracer Directly

Key Concepts

  • Resource attributes describe the source of telemetry (service, model, environment). Set once on the TracerProvider.
  • Span attributes describe a single span. Set per-span in your code.
  • Span processors filter, batch, and perform operations on spans before export.
  • Project name resource attribute. The canonical OpenInference key is openinference.project.name — exposed as ResourceAttributes.PROJECT_NAME from openinference.semconv.resource in Python, SEMRESATTRS_PROJECT_NAME from @arizeai/openinference-semantic-conventions in JS/TS, and set automatically by arize-otel-go’s Options.ProjectName in Go. The Arize collector also accepts model_id as a legacy alias (shown in some older Python/JS examples on this page); both route spans to the same project.
  • OTLP auth headers. The Arize collector accepts both space_id / api_key (canonical, what arize-otel-go sends) and the arize-space-id / arize-api-key aliases shown in the older Python/JS examples. If you copy the raw-OTel Go snippet below into a stack that already uses the arize- prefixed form, pick one and stay consistent.
The most important processor decision for production is which span processor to use:

Batch vs Simple Span Processor

A span processor controls when and how spans are exported. Choose based on your environment:
The SimpleSpanProcessor is synchronous and blocking. Use BatchSpanProcessor for production.
Once your tracer is running, you’ll often want to attach more context to the span currently in flight:

Get the Current Span

Access the current span at any point to enrich it with additional information:
Running multiple apps from one codebase, or splitting traffic across environments? You can split spans across projects:

Route Spans to Multiple Projects

To route traces from one application to multiple Arize spaces or projects, use register_with_routing from arize-otel:
register_with_routing uses ARIZE_API_KEY from your 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 more complex routing (e.g., by span attribute) — route at the OTel Collector layer instead. See OTEL Collector deployment patterns.
If you operate a centralized OpenTelemetry Collector serving many teams or spaces, see the shared-collector pattern that forwards arize-space-id from inbound request metadata — avoids redeploying the collector each time a new space is added.

Next step

Keep sensitive data out of your traces with masking and PII redaction:

Next: Mask and Redact Data