
See here for an end-to-end example of a manually instrumented application.
Google Colab
colab.research.google.com
Semantic Conventions
openinference
Configuring a Tracer
Configuring an OTel tracer involves some boilerplate code that the instrumentors inphoenix.trace take care of for you. If you’re manually instrumenting your application, you’ll need to implement this boilerplate yourself:
- A resource represents an origin (e.g., a particular service, or in this case, a project) from which your spans are emitted.
- Span processors filter, batch, and perform operations on your spans prior to export.
- Your tracer provides a handle for you to create spans and add attributes in your application code.
- The collector (e.g., Phoenix) receives the spans exported by your application.
If you’re using Phoenix Cloud or a local Phoenix with auth enabled:Modify your span exporter to include your API key:
Creating spans
To create a span, you’ll typically want it to be started as the current span.start_span to create a span without making it the current span. This is usually done to track concurrent or asynchronous operations.
Creating nested spans
If you have a distinct sub-operation you’d like to track as a part of another one, you can create span to represent the relationship:child will be tracked as a nested span under parent.
Creating spans with decorators
It’s common to have a single span track the execution of an entire function. In that scenario, there is a decorator you can use to reduce code:do_work() and ending it when do_work() is finished.
To use the decorator, you must have a tracer instance in scope for your function declaration.
If you need to add attributes or events then it’s less convenient to use a decorator.
Get the current span
Sometimes it’s helpful to access whatever the current span is at a point in time so that you can enrich it with more information.Add attributes to a span
Attributes let you attach key/value pairs to a spans so it carries more information about the current operation that it’s tracking.operation. When adding custom attributes, it’s best practice to vendor your attributes (e.x. mycompany.) so that your attributes do not clash with semantic conventions.

