search

open-telemetry / opentelemetry-operator

Kubernetes Operator for OpenTelemetry Collector
Apache License 2.0
1.18k stars 421 forks source link

Python Auto-instrumentation: Conflict dependencies versions #1885

Open ChouMeriam21 opened 1 year ago

ChouMeriam21 commented 1 year ago

Hello!

I encountered an issue while using the OpenTelemetry auto-instrumentation to instrument a Python application that relies on urllib3 library version 1.26.14. According to the documentation, this version is supposed to be supported by the OpenTelemetry operator (ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.39b0), which I used as the image for the Instrumentation resource in Kubernetes.

Unfortunately, during deployment, I encountered a conflict error that prevented the creation of my pod.

image

srikanthccv commented 1 year ago

Could you share the complete error/stack trace?

ChouMeriam21 commented 1 year ago

Yes of course, here's the complete error trace: image image

ChouMeriam21 commented 1 year ago

I had to change the versions of the following packages to make the auto instrumentation works :

Is there any other way ? Especially that there are some packages as requests and packaging that had to endure a downgrade which is not the desired behaviour.

lusains commented 11 months ago

image

autoinstrumentation-python:0.40b0，How to fix it~

sy-be commented 8 months ago

I'd like to add some more context here.

When an init container for autoinstrumentation runs, it installs all of the packages and their dependencies listed in the requirements.txt file. In case with urllib3 it installs the latest available and supported version (which atm is 2.1.0). However if the application code specifies a different version in the corresponding Python environment (e.g. 1.26.14), this unfortunately breaks the application as PYTHONPATH is set to:

PYTHONPATH="/otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation:/otel-auto-instrumentation-python"

which overrides the import path for the urllib3. This in turn breaks other dependencies which rely on functionality of urllib3 1.26.14 which is a different major version.

A simple solution would be to somehow prepend the PYTHONPATH which whichever environment is used by the application. Another, possibly a better way, would be to prevent installation of packages inside /otel-auto-instrumentation-python - only install the instrumentation libraries without any other dependencies.

sy-be commented 8 months ago

This is somewhat similar to https://github.com/open-telemetry/opentelemetry-operator/issues/1884, however in my case, I do not set PYTHONPATH anywhere and when this env var is set - it overrides the path with opentelemetry-autoinstrumentation and the libraries there.