You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Bumping the Python baseline](#bumping-the-python-baseline)
47
48
-[Adding support for a new Python release](#adding-support-for-a-new-python-release)
@@ -307,8 +308,9 @@ The continuous integration overrides that environment variable with as per the c
307
308
308
309
Below is a checklist of things to be mindful of when implementing a new instrumentation or working on a specific instrumentation. It is one of our goals as a community to keep the implementation specific details of instrumentations as similar across the board as possible for ease of testing and feature parity. It is also good to abstract as much common functionality as possible.
309
310
310
-
- Find or Create a new [Issue](https://github.com/open-telemetry/opentelemetry-python-contrib/issues) describing the framework to instrument and its use cases to support with OpenTelemetry.
311
+
- Find or create a new [Issue](https://github.com/open-telemetry/opentelemetry-python-contrib/issues) describing the tool or framework to instrument and its use cases to support with OpenTelemetry.
311
312
- Be familiar with the [expectations from contributors](#expectations-from-contributors) that apply.
313
+
- If you're a tool or framework maintainer, please consider using the OpenTelemetry API directly to support [native instrumentation](#guidelines-for-native-opentelemetry-instrumentation) instead of adding a new community instrumentation library.
312
314
- Follow semantic conventions
313
315
- The instrumentation should follow the semantic conventions defined [here](https://github.com/open-telemetry/semantic-conventions/tree/main/docs).
314
316
- To ensure consistency, we encourage contributions that align with [STABLE](https://opentelemetry.io/docs/specs/otel/document-status/#lifecycle-status) semantic conventions if available. This approach helps us avoid potential confusion and reduces the need to support multiple outdated versions of semantic conventions. However, we are still open to considering exceptional cases where changes are well justified.
@@ -386,6 +388,16 @@ Instrumentations that relate to [Generative AI](https://opentelemetry.io/docs/sp
386
388
387
389
OpenTelemetry is an open source community, and as such, greatly encourages contributions from anyone interested in the project. With that being said, there is a certain level of expectation from contributors even after a pull request is merged, specifically pertaining to instrumentations. The OpenTelemetry Python community expects contributors to maintain a level of support and interest in the instrumentations they contribute. This is to ensure that the instrumentation does not become stale and still functions the way the original contributor intended. Some instrumentations also pertain to libraries that the current members of the community are not so familiar with, so it is necessary to rely on the expertise of the original contributing parties.
388
390
391
+
### Guidelines for native OpenTelemetry instrumentation
392
+
393
+
The preferred approach to supporting instrumentation of a tool or framework is native OpenTelemetry instrumentation. Compared to adding a new instrumentation library to this community repository, native instrumentation is better for:
394
+
395
+
* continued support by framework experts long-term
396
+
* access to more context for critical paths and correlations
397
+
* granularity and performance
398
+
399
+
To support native instrumentation, the tool or framework should use the [OpenTelemetry API](https://opentelemetry-python.readthedocs.io/en/latest/) directly to emit traces, metrics, and logs.
0 commit comments