open-telemetry / open-telemetry/opentelemetry-python-contrib
Automatic Instrumentation: docs improvements and sanity check
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 1.1k
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 16
Description
After wasting half a day trying to figure out why even the simplest auto instrumentation examples for several different frameworks don't work (i.e. they don't emit anything to the console or the OTEL collector), I eventually found the reason: the opentelemetry-distro package was not installed. So two issues:
- The docs mention
The opentelemetry-distro package installs the API, SDK, and the opentelemetry-bootstrap and opentelemetry-instrument toolsand then proceed to describe theopentelemetry-bootstrapcommand, which seems like a "quick start" shortcut that installs a bunch ofopentelementry-*packages that I don't care for. All I (thought I) needed wasopentelemetry-instrumentand a few handpicked packages for the libraries/frameworks I want to instrument (plus their dependencies). It is not obvious at all thatopentelemetry-distrois required for auto instrumentation. - There's no error, warning or other indication that something is missing when running
opentelemetry-instrument, it just defaults to a no-op. I'd expect the auto instrumentation logic that currently lives inopentelemetry-bootstrapto be inopentelemetry-instrument, or if for some reason that's not possible or desirable, to get at least a warning if it's missing.
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 reviewing the automatic instrumentation documentation around opentelemetry-distro, opentelemetry-bootstrap, and opentelemetry-instrument. Then inspect the behavior of opentelemetry-instrument when opentelemetry-distro is absent. Done means the required package is clearly documented and the missing-package behavior is explicitly addressed with the project’s chosen outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, documentation, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100