Replies: 2 comments
-
|
Suggest that we convert this issue into a discussion, I prefer to keep issues for things that can be closed with a specific PR. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The OpenTelemetry Python SDK currently provides the ability for users to auto-instrument their code. While auto-instrumentation itself has not been spec'd out explicitly, other languages have implemented their own mechanisms for auto-instrumenting code. Java even has a dedicated product and repository solely for instrumenting with OpenTelemetry without any code.
Our current approach to auto-instrumentation in terms of support and feature set is: "implement this feature for manual instrumentation and hope that it works for auto-instrumentation". We then retroactively fix bugs that come up. As OpenTelemetry Python is becoming more mature, and it is become more evident that auto instrumentation is a very used/desired feature, we should probably treat it as a top-level product/offering rather than a feature. This will mean some additions in our development process, including:
This will hopefully reduce the amount of issues and questions related to auto-instrumentation, as well as make our auto-instrumentation product more robust and less error-prone. Given our limited resourcing, I suggest we take these tasks one step at a time and iteratively change our codebase to reflect the rising importance of auto-instrumentation (we can maybe start with documentation). I'm also wondering how we would want to include testing for auto-instrumentation (do unit tests even make sense/add any value?)
Thoughts? @aabmass @srikanthccv @ocelotl @owais @jeremydvoss
Beta Was this translation helpful? Give feedback.
All reactions