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.
Let your coding agent set this up. Works with Claude Code, Codex, Cursor, and OpenCode.
Start Phoenix
In one terminal, start Phoenix and leave it running. It serves at http://localhost:6006:
Already have a Phoenix deployment? Skip this step. px setup can point at any running Phoenix, including a self-hosted one.
Add tracing with a coding agent
In a new terminal, from your app’s root directory, run one of these:
px setup hands the instrumentation to your coding agent and waits until a real trace arrives. It can also install the Phoenix skills so your agent can query what you capture. See Connect a project with px setup for the full flow, CI usage, and unsupported agents.
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.
@arizeai/phoenix-otel re-exports the OpenInference tracing helpers and context utilities, so Phoenix users can register tracing and add decorators or span helpers from the same package.
For detailed API documentation, consult the respective documentation sites.
Phoenix does not ship a phoenix-otel-go wrapper. Install the OpenInference Go semconv + instrumentation packages plus the stock OpenTelemetry Go SDK:
The semconv package provides typed constants for the wire-format-stable attribute keys; instrumentation provides context-attribute helpers (session, user, metadata, tags, suppression).
Setting Up Tracing#
Configure the OpenTelemetry Go SDK with an OTLP/HTTP exporter pointed at Phoenix, then obtain a tracer. For a remote deployment, set PHOENIX_COLLECTOR_ENDPOINT and, if it has authentication enabled, PHOENIX_API_KEY.
Using Helpers#
Your tracer object can now be used in two primary ways:
1. Tracing a function#
Go has no decorator syntax. Wrap the function body in a tracer.Start span and set input / output / span-kind attributes manually using the OpenInference Go semconv constants:
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#
Go does not have a with statement; use tracer.Start + defer span.End() to scope a span to a block:
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:
| Span Kind | Description |
|---|---|
| LLM | A span that represents a call to a Large Language Model (LLM). For example, an LLM span could be used to represent a call to OpenAI or Llama for chat completions or text generation. |
| EMBEDDING | A span that represents a call to an LLM or embedding service for generating embeddings. For example, an Embedding span could be used to represent a call to OpenAI to get an ada embedding for retrieval. |
| CHAIN | A span that represents a starting point or a link between different LLM application steps. For example, a Chain span could be used to represent the beginning of a request to an LLM application or the glue code that passes context from a retriever to an LLM call. |
| RETRIEVER | A span that represents a data retrieval step. For example, a Retriever span could be used to represent a call to a vector store or a database to fetch documents or information. |
| RERANKER | A span that represents the reranking of a set of input documents. For example, a cross-encoder may be used to compute the input documents’ relevance scores with respect to a user query, and the top K documents with the highest scores are then returned by the Reranker. |
| TOOL | A span that represents a call to an external tool such as a calculator, weather API, or any function execution that is invoked by an LLM or agent. |
| AGENT | A span that encompasses calls to LLMs and Tools. An agent describes a reasoning block that acts on tools using the guidance of an LLM. |
| GUARDRAIL | A span that represents calls to a component to protect against jailbreak user input prompts by taking action to modify or reject an LLM’s response if it contains undesirable content. For example, a Guardrail span could involve checking if an LLM’s output response contains inappropriate language, via a custom or external guardrail library, and then amending the LLM response to remove references to the inappropriate language. |
| EVALUATOR | A span that represents a call to a function or process performing an evaluation of the language model’s outputs. Examples include assessing the relevance, correctness, or helpfulness of the language model’s answers. |
| DECISION | Experimental. A span that represents a call to a decision model, which scores or selects among candidate options provided in the request rather than generating free-form text. Support is still being built out and no decision-model provider is fully supported yet. |
Chains#
Set the OpenInference span kind to CHAIN on any span that represents a step or glue point in your application. Inputs and outputs go on the same span via the semconv constants:
Agents#
Use the AGENT span kind for spans that wrap an LLM-driven reasoning loop. Set agent.name to identify the agent across calls:
Tools#
Use the TOOL span kind for spans that wrap calls to external functions, APIs, or any tool the agent invokes. The tool name and inputs are conventionally attached to the same span:
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_attributesget_input_attributesget_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_inputshould exactly match the input signature of the decorated function. - The input signature of
process_outputhas 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_inputandprocess_outputshould 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.
Function Wrapper#
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 use helper functions from @arizeai/phoenix-otel that produce valid OpenInference attributes for LLM spans:
getLLMAttributesdefaultProcessInputdefaultProcessOutput
For OpenAI, these functions might look like this:
Function Wrapper#
When using withSpan to wrap functions, you can pass processInput and processOutput functions as options. These should satisfy the following:
- The input signature of
processInputshould exactly match the input signature of the wrapped function. - The input signature of
processOutputhas a single argument, the output of the wrapped function. This argument accepts the returned value when the wrapped function is a sync or async function. - Both
processInputandprocessOutputshould output a dictionary mapping attribute names to values.
For SDKs with OpenInference Go auto-instrumentation, see OpenAI Go SDK and Anthropic SDK Go — no manual span code required. For SDKs without auto-instrumentation, attach model and token attributes directly using semconv:
Additional Features#
The OpenInference Tracer shown above respects context Managers for Suppressing Tracing & Adding Metadata
Suppress Tracing#
Use instrumentation.WithSuppression to mark a context such that any OpenInference-aware Go instrumentor (e.g. the OpenAI and Anthropic Go transports / middlewares) skips span emission for calls descended from it. Typical use: evaluator or grader code that itself calls an LLM but should not appear in the customer’s product trace.
For manual spans you author yourself, check the context before calling tracer.Start if you want to honor suppression in your own code.
Using Context Attributes#
Use the helpers in github.com/Arize-ai/openinference/go/openinference-instrumentation to store session, user, metadata, and tags on context.Context. Auto-instrumentors (OpenAI Go, Anthropic Go) automatically apply these to every LLM span descended from the context:
For manual spans you author yourself, set the same attributes directly via the semconv keys (SessionID, UserID, Metadata, TagTags) after tracer.Start.
Adding Images to your Traces#
OpenInference includes message types that can be useful in composing text and image or other file inputs and outputs:
For SDKs with OpenInference Go auto-instrumentation (OpenAI Go, Anthropic Go), multimodal content is captured automatically when you call the SDK with image-containing messages — no per-span code required.
For manual spans, attach image content using the indexed llm.input_messages.{i}.message.contents.{j}.* attributes from github.com/Arize-ai/openinference/go/openinference-semantic-conventions. The Python openinference.instrumentation message-builder helpers do not yet have a Go equivalent — refer to the OpenInference spec for the full multimodal attribute taxonomy.

