What are you trying to achieve?
In OBI, we need to detect if a process is already instrumented by an SDK, in order to avoid duplication.
This is currently done via heuristics (observing network traffic and classifying OTLP exports), and it has the downside of being an "all or nothing" solution, OBI stops instrumenting the service completely, instead of complementing it with only instrumentations the application is missing (for example, the application instruments HTTP / gRPC calls, but not database calls, DNS and so on)
What did you expect to see?
If OBI can know which instrumentations are registered on a service (by a given SDK), it can dynamically turn on only the missing instrumentations.
This is useful for OBI but of course this information is available for all external readers, that can make decisions based on the registered instrumentations.
Additional context.
Proposed solution is to extend the Process Context Protocol to also include information about registered instrumentations
I could extend with more details if needed, or in full once the issue is accepted and i can open a PR with the written spec
Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
What are you trying to achieve?
In OBI, we need to detect if a process is already instrumented by an SDK, in order to avoid duplication.
This is currently done via heuristics (observing network traffic and classifying OTLP exports), and it has the downside of being an "all or nothing" solution, OBI stops instrumenting the service completely, instead of complementing it with only instrumentations the application is missing (for example, the application instruments HTTP / gRPC calls, but not database calls, DNS and so on)
What did you expect to see?
If OBI can know which instrumentations are registered on a service (by a given SDK), it can dynamically turn on only the missing instrumentations.
This is useful for OBI but of course this information is available for all external readers, that can make decisions based on the registered instrumentations.
Additional context.
Proposed solution is to extend the Process Context Protocol to also include information about registered instrumentations
I could extend with more details if needed, or in full once the issue is accepted and i can open a PR with the written spec
Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.