Riccardo Magliocchetti 88e5bfc630 Add a basic http OpAMP client (#3635)
* Add a basic http OpAMP client

* Add some docs and hook it into the system

Still not building content

* Add default value of 30 seconds to heartbeat message interval

* Fix docs build

* More docs improvements

* Fix spellcheck

* Remove local workaround

* Generate workflows and add to release script

* Fix typos in opamp lint commands

* Fix requirements for pylint

* Update opamp/opentelemetry-opamp-client/pyproject.toml

* Recreate requirements

* Add missing opentelemetry-api dependency

* Fix tox test commands

Drop opentelemetry api fixed version from requirements

* Fix tox

* Add baseline of vcrpy 7.0.0

* Ignore pb2 module in pylintrc

* Bump pylint to match the version in core

* Silence pylint warnings

* Don't trace opamp client own http requests

* Permit to pass a custom transport to client

And a custom session to RequestsTransport

* Don't bump pylint after all

* Fix pylint

* Try to typecheck opamp client

* Bump version after rebase

* Fix typecheck in client

* Please pyright in strict mode

* No need for functions and methods to be private since _opamp module is already private

* Add missing protobuf package installation for typecheck

* Fix docs generation

* Fix pyright exclusion rule for proto

Missed .pyi exclusion

* Feedback

* Don't flush the queue at exit

* Log transport send exceptions

* Update example to not assume that the config is in json format

* Fix typo in exception

* Looks like it's implementers

* Add timeout to stop to forward to threads join

* Clarify doc

* Fix typo in var name

* Add support for mTLS

* Add helpers for handling of ReportFullState ServerToAgent flag

Introducing basic handling of the ReportsEffectiveConfig capability

* Remove backup file

* Rewrite opamp_proto_codegen.sh to use uv

* Make the package releasable independently

* Send full state at connection

* Add 3.14 test run

* Add changelog entry

* Add missing ReportsEffectiveConfig capability in documentation

* Start version from 0.1b0 and re-record e2e tests

* Record tests against opentelemetry-go

---------

Co-authored-by: Emídio Neto <9735060+emdneto@users.noreply.github.com>
2026-03-05 16:36:54 +01:00
2022-09-15 23:42:49 +05:30
2020-04-08 13:17:31 -07:00
2021-09-27 19:58:13 +00:00
2026-03-05 16:36:54 +01:00

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

GitHub release (latest by date including pre-releases) Codecov Status license
Build Status 0 Build Status 1 Beta

Contributing   •   Instrumentations

OpenTelemetry Python Contrib

The Python auto-instrumentation libraries for OpenTelemetry (per OTEP 0001)

Index

Installation

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

Please note that these libraries are currently in beta, and shouldn't generally 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.

The instrumentation/ directory includes OpenTelemetry instrumentation packages, which can be installed separately as:

pip install opentelemetry-instrumentation-{integration}

To install the development versions of these packages instead, clone or fork this repo and do an editable install:

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

Releasing

Maintainers release new versions of the packages in opentelemetry-python-contrib on a monthly cadence. See releases 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 a 1.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:

Releasing a package as 1.0 stable

To release a package as 1.0 stable, the package:

  • SHOULD have a CODEOWNER. To become one, submit an issue and explain why you meet the responsibilities found in CODEOWNERS.
  • 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 the BaseInstrumentor class, these are documented
  • After the release of 1.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.

Semantic Convention status of instrumentations

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 for HTTP-related instrumentations, but will eventually cover all types. Please refer to the semconv status column of the instrumentation README of the current status of instrumentations' semantic conventions. The possible values are development, stable and migration referring to status of that particular semantic convention. Migration refers to an instrumentation that currently supports the migration plan.

Contributing

See CONTRIBUTING.md

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

Meeting notes are available as a public Google doc.

Maintainers

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

Approvers

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

Emeritus Maintainers

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

Emeritus Approvers

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

Thanks to all of our contributors!

Repo contributors
Description
OpenTelemetry instrumentation for Python modules
Readme Apache-2.0 78 MiB
Languages
Python 99.7%
Shell 0.3%