arize-phoenix-otel
Provides a lightweight wrapper around OpenTelemetry primitives with Phoenix-aware defaults. Phoenix Otel also gives you acces to tracing decorators for common GenAI patterns.
These defaults are aware of environment variables you may have set to configure Phoenix:
PHOENIX_COLLECTOR_ENDPOINT
PHOENIX_PROJECT_NAME
PHOENIX_CLIENT_HEADERS
PHOENIX_API_KEY
PHOENIX_GRPC_PORT
Installation
Install via pip
.
Examples
The phoenix.otel
module provides a high-level register
function to configure OpenTelemetry
tracing by setting a global TracerProvider
. The register function can also configure headers
and whether or not to process spans one by one or by batch.
Quickstart
This is all you need to get started using OTel with Phoenix! register
defaults to sending spans
to an endpoint at http://localhost
using gRPC.
Phoenix Authentication
If the PHOENIX_API_KEY
environment variable is set, register
will automatically add anauthorization
header to each span payload.
Configuring the collector endpoint
There are two ways to configure the collector endpoint:
Using environment variables
Using the
endpoint
keyword argument
Using environment variables
If you're setting the PHOENIX_COLLECTOR_ENDPOINT
environment variable, register
will
automatically try to send spans to your Phoenix server using gRPC.
Specifying the endpoint
directly
When passing in the endpoint
argument, you must specify the fully qualified endpoint. For
example, in order to export spans via HTTP to localhost, use Pheonix's HTTP collector endpoint:http://localhost:6006/v1/traces
. The default gRPC endpoint is different: http://localhost:4317
.
If the PHOENIX_GRPC_PORT
environment variable is set, it will override the default gRPC port.
Additionally, the protocol
argument can be used to enforce the OTLP transport protocol
regardless of the endpoint specified. This might be useful in cases such as when the GRPC
endpoint is bound to a different port than the default (4317). The valid protocols are:
"http/protobuf", and "grpc".
Additional configuration
register
can be configured with different keyword arguments:
project_name
: The Phoenix project name (orPHOENIX_PROJECT_NAME
env. var)headers
: Headers to send along with each span payload (orPHOENIX_CLIENT_HEADERS
env. var)batch
: Whether or not to process spans in batch
A drop-in replacement for OTel primitives
For more granular tracing configuration, these wrappers can be used as drop-in replacements for OTel primitives:
Wrappers have Phoenix-aware defaults to greatly simplify the OTel configuration process. A specialendpoint
keyword argument can be passed to either a TracerProvider
, SimpleSpanProcessor
orBatchSpanProcessor
in order to automatically infer which SpanExporter
to use to simplify setup.
Using environment variables
Specifying the endpoint
directly
Further examples
Users can gradually add OTel components as desired:
Configuring resources
Using a BatchSpanProcessor
Specifying a custom GRPC endpoint
Last updated
Was this helpful?