Skip to main content

OpenInference OTEL Tracing

This documentation provides a guide on using OpenInference OTEL tracing decorators and methods for instrumenting functions, chains, agents, and tools using OpenTelemetry. These tools can be combined with, or used in place of, OpenTelemetry instrumentation code. They are designed to simplify the instrumentation process.

Installation

Ensure you have Phoenix OTEL installed:
Version arize-phoenix-otel>=0.16.0 is required for the examples on this page. Starting in 0.16.0, phoenix.otel re-exports the OpenInference context managers (using_session, using_user, using_metadata, using_tags, using_attributes, using_prompt_template, suppress_tracing) and semantic conventions (SpanAttributes, OpenInferenceSpanKindValues, OpenInferenceMimeTypeValues) directly — no need to also install openinference-instrumentation or openinference-semantic-conventions.On older versions, import the same symbols from openinference.instrumentation and openinference.semconv.trace instead.

Setting Up Tracing


Using Helpers

Your tracer object can now be used in two primary ways:

1. Tracing a function

This entire function will appear as a Span in Phoenix. Input and output attributes in Phoenix will be set automatically based on my_func’s parameters and return. The status attribute will also be set automatically.

2. As a with clause to trace specific code blocks

The code within this clause will be captured as a Span in Phoenix. Here the input, output, and status must be set manually. This approach is useful when you need only a portion of a method to be captured as a Span.

OpenInference Span Kinds

OpenInference Span Kinds denote the possible types of spans you might capture, and will be rendered different in the Phoenix UI. The openinference.span.kind attribute is required for all OpenInference spans and identifies the type of operation being traced. The span kind provides a hint to the tracing backend as to how the trace should be assembled. Valid values include:

Chains

Using Context Managers

Using Decorators

Using JSON Output
Overriding Span Name

Agents

Using Context Managers

Using Decorators


Tools

Using Context Managers

Using Decorators

Overriding Tool Name

LLMs

Like other span kinds, LLM spans can be instrumented either via a context manager or via a decorator pattern. It’s also possible to directly patch client methods. While this guide uses the OpenAI Python client for illustration, in practice, you should use the OpenInference auto-instrumentors for OpenAI whenever possible and resort to manual instrumentation for LLM spans only as a last resort. To run the snippets in this section, set your OPENAI_API_KEY environment variable.

Context Manager

Decorator

This decorator pattern above works for sync functions, async coroutine functions, sync generator functions, and async generator functions. Here’s an example with an async generator.

Method Patch

It’s also possible to directly patch methods on a client. This is useful if you want to transparently use the client in your application with instrumentation logic localized in one place.
The snippets above produce LLM spans with input and output values, but don’t offer rich UI for messages, tools, invocation parameters, etc. In order to manually instrument LLM spans with these features, users can define their own functions to wrangle the input and output of their LLM calls into OpenInference format. These richer LLM attribute helpers are not re-exported from phoenix.otel — install openinference-instrumentation to access them:
  • get_llm_attributes
  • get_input_attributes
  • get_output_attributes
For OpenAI, these functions might look like this:

Context Manager

When using a context manager to create LLM spans, these functions can be used to wrangle inputs and outputs.

Decorator

When using the tracer.llm decorator, these functions are passed via the process_input and process_output parameters and should satisfy the following:
  • The input signature of process_input should exactly match the input signature of the decorated function.
  • The input signature of process_output has a single argument, the output of the decorated function. This argument accepts the returned value when the decorated function is a sync or async function, or a list of yielded values when the decorated function is a sync or async generator function.
  • Both process_input and process_output should output a dictionary mapping attribute names to values.
When decorating a generator function, process_output should accept a single argument, a list of the values yielded by the decorated function.
Then the decoration is the same as before.

Method Patch

As before, it’s possible to directly patch the method on the client. Just ensure that the input signatures of process_input and the patched method match.

Additional Features

The OpenInference Tracer shown above respects context Managers for Suppressing Tracing & Adding Metadata

Suppress Tracing

Using Context Attributes

Adding Images to your Traces

OpenInference includes message types that can be useful in composing text and image or other file inputs and outputs: