Repository files navigation

Getting Started   •  API Documentation   •  Getting In Touch (GitHub Discussions)

Contributing   •  Instrumentations

The Python auto-instrumentation libraries forOpenTelemetry (perOTEP 0001)

• Installation
• Releasing
  • Releasing a package as1.0 stable
• Semantic Convention status of instrumentations
• Contributing
• Thanks to all the people who already contributed

This repository includes installable packages for each instrumented library. Libraries that produce telemetry data should only depend onopentelemetry-api,and defer the choice of the SDK to the application developer. Applications maydepend onopentelemetry-sdk or another package that implements the API.

Please note that these libraries are currently inbeta, and shouldn'tgenerally be used in production environments.

Unless explicitly stated otherwise, any instrumentation here for a particular library is not developed or maintained by the authors of such library.

Theinstrumentation/directory includes OpenTelemetry instrumentation packages, which can be installedseparately as:

pip install opentelemetry-instrumentation-{integration}

To install the development versions of these packages instead, clone or forkthis repo and do aneditableinstall:

pip install -e ./instrumentation/opentelemetry-instrumentation-{integration}

Maintainers release new versions of the packages inopentelemetry-python-contrib on a monthly cadence. Seereleases for all previous releases.

Contributions that enhance OTel for Python are welcome to be hosted upstream for the benefit of group collaboration. Maintainers will look for things like good documentation, good unit tests, and in general their own confidence when deciding to release a package with the stability guarantees that are implied with a1.0 release.

To resolve this, members of the community are encouraged to commit to becoming a CODEOWNER for packages in-contrib that they feel experienced enough to maintain. CODEOWNERS can then follow the checklist below to release-contrib packages as 1.0 stable:

To release a package as1.0 stable, the package:

• SHOULD have a CODEOWNER. To become one, submit an issue and explain why you meet the responsibilities found inCODEOWNERS.
• MUST have unit tests that cover all supported versions of the instrumented library.
  • e.g. Instrumentation packages might use different techniques to instrument different major versions of python packages
• MUST have clear documentation for non-obvious usages of the package
  • e.g. If an instrumentation package uses flags, a token as context, or parameters that are not typical of theBaseInstrumentor class, these are documented
• After the release of1.0, a CODEOWNER may no longer feel like they have the bandwidth to meet the responsibilities of maintaining the package. That's not a problem at all, life happens! However, if that is the case, we ask that the CODEOWNER please raise an issue indicating that they would like to be removed as a CODEOWNER so that they don't get pinged on future PRs. Ultimately, we hope to use that issue to find a new CODEOWNER.

In our efforts to maintain optimal user experience and prevent breaking changes for transitioning into stable semantic conventions, OpenTelemetry Python is adopting the semantic convention migration plan for several instrumentations. Currently this plan is only being adopted forHTTP-related instrumentations, but will eventually cover all types. Please refer to thesemconv status column of theinstrumentation README of the current status of instrumentations' semantic conventions. The possible values aredevelopment,stable andmigration referring tostatus of that particular semantic convention.Migration refers to an instrumentation that currently supports the migration plan.

SeeCONTRIBUTING.md

We meet weekly on Thursday at 9AM PT. The meeting is subject to change depending on contributors' availability. Check theOpenTelemetry community calendar for specific dates and for the Zoom link.

Meeting notes are available as a publicGoogle doc. For edit access, get in touch onGitHub Discussions.

• Aaron Abbott, Google
• Leighton Chen, Microsoft
• Riccardo Magliocchetti, Elastic
• Shalev Roda, Cisco

For more information about the maintainer role, see thecommunity repository.

• Emídio Neto, PicPay
• Jeremy Voss, Microsoft
• Owais Lone, Splunk
• Pablo Collins, Splunk
• Sanket Mehta, Cisco
• Srikanth Chekuri, signoz.io
• Tammy Baylis, SolarWinds

For more information about the approver role, see thecommunity repository.

• Alex Boten, Lightstep
• Diego Hurtado, Lightstep
• Owais Lone, Splunk
• Yusuke Tsutsumi, Google

For more information about the emeritus role, see thecommunity repository.

• Ashutosh Goel, Cisco
• Héctor Hernández, Microsoft
• Nikolay Sokolik, Oxeye
• Nikolay Sokolik, Oxeye
• Nathaniel Ruiz Nowell, AWS

For more information about the emeritus role, see thecommunity repository.