feat(smolagents): add entrypoint for use in opentelemetry-instrument

[codefromthecrypt]

I mentioned this to @mikeldking, that openinference can become automatically enabled with opentelemetry's zero code approach for python, by adding entrypoints into the pyproject.toml.

Specifically, after this, as long as you have the dependencies of your main code, plus openinference-instrumentation-smolagents, and env exported with standard variables, if you launch with opentelemetry-instrument, traces will magically appear.

opentelemetry-instrument python main.py

Before adding to all projects, I wanted to check with smolagents first, if this is ok with y'all. I would love to be able to showcase this with Elastic Distribution of OpenTelemetry (EDOT) and the diff makes it all perfectly invisible.

diff --git a/examples/python/openinference/smolagents/main.py b/examples/python/openinference/smolagents/main.py
index 7d54c87..697f7a5 100644
--- a/examples/python/openinference/smolagents/main.py
+++ b/examples/python/openinference/smolagents/main.py
@@ -1,11 +1,7 @@
 import os
 
-from openinference.instrumentation.smolagents import SmolagentsInstrumentor
 from smolagents import DuckDuckGoSearchTool, OpenAIServerModel, ToolCallingAgent
 
-SmolagentsInstrumentor().instrument()
-
-
 def main():
     model = OpenAIServerModel(model_id=os.getenv("CHAT_MODEL", "gpt-4o-mini"))
 
diff --git a/examples/python/openinference/smolagents/requirements.txt b/examples/python/openinference/smolagents/requirements.txt
index 8d8c23b..5220f5a 100644
--- a/examples/python/openinference/smolagents/requirements.txt
+++ b/examples/python/openinference/smolagents/requirements.txt
@@ -3,4 +3,5 @@ smolagents[openai]~=1.7.0
 opentelemetry-sdk~=1.30.0
 opentelemetry-exporter-otlp-proto-http~=1.30.0
 opentelemetry-distro~=0.51b0
-openinference-instrumentation-smolagents~=0.1.3
+# openinference-instrumentation-smolagents~=0.1.3
+-e /Users/adriancole/oss/openinference/python/instrumentation/openinference-instrumentation-smolagents

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[codefromthecrypt]

I have read the CLA Document and I hereby sign the CLA

[nate-mar]

Cool! TIL! Thanks for the contribution. lgtm!

[codefromthecrypt]

Just verified this works like a champ with latest release. Should I raise PRs for the others? If so, same PR for all others, or one each like this?

[mikeldking]

Just verified this works like a champ with latest release. Should I raise PRs for the others? If so, same PR for all others, or one each like this

Thanks so much for this @codefromthecrypt can do them all at once no problem. We have a single release please pipeline now. Should just work

[codefromthecrypt]

ok I may be somewhat blind now, but all the rest are done in #1278 ;)

[aymeric-roucher]

@codefromthecrypt maintainer of smolagents here: could you explain what this changes for instrumentation, and if we have actions to take to make it work?

[nate-mar]

Hi @aymeric-roucher ! As far as I understand, this doesn't change anything with the existing instrumentation for smolagents. It just gives users more optionality for setting up smolagents instrumentation with their apps, by allowing them to remove some boilerplate otel instrumentation code (via a run time arg instead) , if they so desire.

[codefromthecrypt]

@aymeric-roucher I concur with @nate-mar and was going to propose an instruction change PR today for smolagents repo. You can then assess that to see if you prefer the before or after, but the existing instructions still work!

[aymeric-roucher]

Hi all!

Bear in mind neither I nor smolagents user don't really care about the low level detail. Our common objective is "be able to robustly instrument a smolagents agent in as few lines of code as possible, with the asymptotic objective of 0 lines of code". More than 1 line for instrumentation is probably too much (bear in mind neither me nor my users care about setting up the system "in the right way", we just want it to work), 0 would be nice (but you probably at least need to set the endpoint url).

So please assume my only goal is to reduce the lines of code needed to implement instrumentation compared to our explanation in the doc.

The previous recommended (because shortest) implementation is:

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

from openinference.instrumentation.smolagents import SmolagentsInstrumentor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor

endpoint = "http://0.0.0.0:6006/v1/traces"
trace_provider = TracerProvider()
trace_provider.add_span_processor(SimpleSpanProcessor(OTLPSpanExporter(endpoint)))

SmolagentsInstrumentor().instrument(tracer_provider=trace_provider)

This is 12 lines.

What is the new shortest possible implementation that works?

[axiomofjoy]

Hey @aymeric-roucher, thanks for the comment! Definitely understand the desire to encapsulate the complexity of using OTel. We have helper functions that will shorten the number of lines of code.

pip install arize-phoenix-otel openinference-instrumentation-smolagents smolagents

from phoenix.otel import register
from openinference.instrumentation.smolagents import SmolagentsInstrumentor

register()
SmolagentsInstrumentor().instrument()

The register function accepts arguments for endpoint and project_name, e.g., register(endpoint="http://127.0.0.1:6006/v1/traces", project_name="smolagents"). By default, traces are sent to localhost on the default Phoenix port for GRPC traces.

The goal of register is to provide users who are not familiar with OpenTelemetry with a simple first-touch experience.

The zero-code approach enabled by this PR is probably best-suited for users who have familiarity with OTel concepts and wish to express those concepts in configuration (e.g., env vars) rather than code.

Let us know if this addresses the pain point you are trying to resolve!

[codefromthecrypt]

if you want to:

• not change how python is run (e.g. not prefix it with opentelemetry-instrument)

And still get the "zero code affect"

• not have to hard-code exporters and things
• Use default ENV variables etc.

You can add the following single line to your source instead

import opentelemetry.instrumentation.auto_instrumentation.sitecustomize

Note that this is undocumented in otel and I'm trying to change that, also there's an outstanding bug where if you don't have PYTHONPATH, you need to set it.

I'm not sure if from phoenix.otel import register does the standard ENV var part or not, so this may be the same thing.

Here's the issue in otel I'm trying to get polished into a more known state, as there are valid reasons to want to do "single line of code" vs "zero code" open-telemetry/opentelemetry-python-contrib#3263

Regardless, I think manual is the least desirable option for new folks as it is easy to get wrong, adds maintenance and also will miss things like metrics when they become in use. I know this is just my opinion.

[axiomofjoy]

Thanks for the context @codefromthecrypt.

Regardless, I think manual is the least desirable option for new folks as it is easy to get wrong, adds maintenance and also will miss things like metrics when they become in use. I know this is just my opinion.

Agree.

I have opened an issue here for incorporating this behavior into phoenix.otel.register and making it truly one-line instrumentation.

[aymeric-roucher]

Thank you @axiomofjoy @codefromthecrypt for your explanations! I'll start by incorporating the short initialization proposed by @axiomofjoy into the implementation.

[codefromthecrypt]

Cool. Link any PR back here for those following. Cheers!

[aymeric-roucher]

@axiomofjoy when I run phoenix serve in a console, then register() in my script, I got the register() correctly pointing to the localhost url that the phoenix serve was listening to. Is there a possibility that that's not the case? In that case how to point either register() or phoenix serve to the correct url?

[axiomofjoy]

@axiomofjoy when I run phoenix serve in a console, then register() in my script, I got the register() correctly pointing to the localhost url that the phoenix serve was listening to. Is there a possibility that that's not the case? In that case how to point either register() or phoenix serve to the correct url?

Hey @aymeric-roucher 👋

By default, Phoenix will listen for HTTP traces on port 6006 and for gRPC traces on port 4317. By default, phoenix.otel.register will configure traces to be exported to the default gRPC port 4317 on localhost. So if a user launches Phoenix locally with the default ports, there should be no issue.

If a user has configured a non-default port or is running a remote instance of Phoenix, they will need to set the endpoint and protocol arguments of register. See here for details.

[axiomofjoy]

@aymeric-roucher As of openinference-instrumentation-smolagents==0.1.6 and arize-phoenix-otel==0.8.0, one-line instrumentation is possible.

from phoenix.otel import register

register(auto_instrument=True)  # automatically instruments all installed OpenInference libraries