open-telemetry / open-telemetry/opentelemetry-python-contrib
otel-auto-instrumentation-python - __sched_cpufree: symbol not found
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 1.1k
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 16
Description
Describe your environment
No response
What happened?
Hello,
I am trying to get the auto instrumentation for my Python apps. It was successfully tested for my Java components.
Instrumentation CRD (based on https://opentelemetry.io/docs/platforms/kubernetes/operator/automatic/)
apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
name: demo-instrumentation
spec:
exporter:
endpoint: http://monitoring-platform-alloy.platform.svc.cluster.local:4317
propagators:
- tracecontext
- baggage
sampler:
type: parentbased_traceidratio
argument: "1"
Also added the needed annotations under spec.template.metadata.annotations in my app:
spec:
template:
metadata:
annotations:
arch-support/amd64: 'true'
arch-support/arm64: 'true'
instrumentation.opentelemetry.io/inject-python: platform/demo-instrumentation
Init-container is properly created named: opentelemetry-auto-instrumentation-python:
Successfully pulled image "ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.53b1
But got the following output on my desired application:
Importing of system_metrics failed, skipping it
Traceback (most recent call last):
File "/otel-auto-instrumentation-python/opentelemetry/instrumentation/auto_instrumentation/_load.py", line 74, in _load_instrumentors
distro.load_instrumentor(
File "/otel-auto-instrumentation-python/opentelemetry/instrumentation/distro.py", line 61, in load_instrumentor
instrumentor: BaseInstrumentor = entry_point.load()
File "/otel-auto-instrumentation-python/importlib_metadata/__init__.py", line 189, in load
module = import_module(match.group('module'))
File "/usr/local/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 883, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/otel-auto-instrumentation-python/opentelemetry/instrumentation/system_metrics/__init__.py", line 100, in <module>
import psutil
File "/otel-auto-instrumentation-python/psutil/__init__.py", line 95, in <module>
from . import _pslinux as _psplatform
File "/otel-auto-instrumentation-python/psutil/_pslinux.py", line 26, in <module>
from . import _psutil_linux as cext
ImportError: Error relocating /otel-auto-instrumentation-python/psutil/_psutil_linux.abi3.so: __sched_cpufree: symbol not found
Steps to Reproduce
Created and applied the CRD, added the needed annotation and got the unexpected log output
Expected Result
Traces are being sent properly to my exporter backend.
Actual Result
Not traces visible getting the error message above exposed
Additional context
No response
Would you like to implement a fix?
None
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the OpenTelemetry Python auto-instrumentation setup with image version 0.53b1 and the reported architecture annotations. Trace loading from opentelemetry/instrumentation/auto_instrumentation/_load.py through system_metrics/init.py, psutil/_pslinux.py, and the _psutil_linux.abi3.so extension. Done means system_metrics loads without the __sched_cpufree error and instrumentation can send traces to the configured exporter.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100