opentelemetry-instrumentation: expose a way to init autoinstrumentation programmatically

[xrmx]

Description

Expose the initialize function used to init auto-instrumentation programmatically in a more conventient way instead of importing sitecustomize and expect its side effects. While at it also update the code to handle the case of PYTHONPATH not set.

from opentelemetry.instrumentation import auto_instrumentation
auto_instrumentation.initialize()

Fixes #3263
Closes #2886

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• tox -e py310-test-opentelemetry-instrumentation

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[xrmx]

This is a draft because I haven't tested it yet outside of unit tests.

[codefromthecrypt]

This works, thanks. Here is how I tested it.

---

I checked out your branch gh pr checkout 3273, then navigated to the instrumentation-genai/opentelemetry-instrumentation-openai-v2/examples/manual directory

Inside there, I replaced requirements.txt with this

openai~=1.63.2

opentelemetry-api@git+https://github.com/open-telemetry/opentelemetry-python.git#egg=opentelemetry-api&subdirectory=opentelemetry-api
opentelemetry-sdk@git+https://github.com/open-telemetry/opentelemetry-python.git#egg=opentelemetry-sdk&subdirectory=opentelemetry-sdk
opentelemetry-semantic-conventions@git+https://github.com/open-telemetry/opentelemetry-python.git#egg=opentelemetry-semantic-conventions&subdirectory=opentelemetry-semantic-conventions
opentelemetry-proto@git+https://github.com/open-telemetry/opentelemetry-python.git#egg=opentelemetry-proto&subdirectory=opentelemetry-proto
opentelemetry-exporter-otlp-proto-common@git+https://github.com/open-telemetry/opentelemetry-python.git#egg=opentelemetry-exporter-otlp-proto-common&subdirectory=exporter/opentelemetry-exporter-otlp-proto-common
opentelemetry-exporter-otlp-proto-grpc@git+https://github.com/open-telemetry/opentelemetry-python.git#egg=opentelemetry-exporter-otlp-proto-grpc&subdirectory=exporter/opentelemetry-exporter-otlp-proto-grpc
../../../../opentelemetry-instrumentation
../../../../opentelemetry-distro
../../../opentelemetry-instrumentation-openai-v2

Then, I replaced main.py with this:

# pylint: skip-file
import os

from openai import OpenAI

from opentelemetry.instrumentation import auto_instrumentation
auto_instrumentation.initialize()

def main():
    client = OpenAI()
    chat_completion = client.chat.completions.create(
        model=os.getenv("CHAT_MODEL", "gpt-4o-mini"),
        messages=[
            {
                "role": "user",
                "content": "Write a short poem on OpenTelemetry.",
            },
        ],
    )
    print(chat_completion.choices[0].message.content)


if __name__ == "__main__":
    main()

Then, I ran dotenv run -- python main.py and it worked!

[codefromthecrypt]

This works, I was missing one dep and adjusted my comment!

[xrmx]

Tested this with a flask app, opentelemetry-instrument still work, in order to work manually the initialize() must be called before importing Flask, I guess the developer experience will depend on the instrumentation.

[codefromthecrypt]

Tested this with a flask app, opentelemetry-instrument still work, in order to work manually the initialize() must be called before importing Flask, I guess the developer experience will depend on the instrumentation.

yeah maybe in general we suggest to init before other imports, though code style might interfere with this.

[codefromthecrypt]

per earlier comments, this is exactly what I was looking for and happy to see it!