Making "methods" instrumentation dynamically updateable

[jackshirazi]

Is your feature request related to a problem? Please describe.

An API that let's the methods instrumentation have methods instrumented at runtime, and also have any existing method instrumentation disabled at runtime
Conceptually, I think 3 API methods, like

• listCurrentInstrumentedMethods
• instrumentMethod(class, method, maybe spankind)
• disableInstrumentedMethod(class, method)

Describe the solution you'd like

Ideally it's just changes in the method instrumentation. But it would need to be accessible from an extension, which means that I think I need to add an interface to the javaagent-bootstrap module, and I'm not sure how acceptable that is. Or are there other ways to make the internal APIs available externally?

Describe alternatives you've considered

An alternative is to reimplement the full instrumentation as an extension and only have that dyamically updateable, leaving the existing one static and using the env var to determine which methods were instrumented so that the new one doesn't try to duplicate instrumentation on those. In some ways, this is the cleaner option, even though it's duplication of code

Additional context

part of open-telemetry/opentelemetry-java-contrib#2416

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.}

[trask]

Instead of 3 API methods, can it be configuration driven, since I think we want a generic way to update instrumentation configuration for other use cases too?

[jackshirazi]

I think that implies polling something. I'd be fine with that. But what? The env var can't change, and I don't think the ConfigProperties are available or even guaranteed mutable. We could use the system property, anything can update that so it's a valid globally usable mutable config option, and polling should be low enough frequency that the synchronization overhead doesn't matter at all. Then it's just a matter of diffing the list on each poll, which is pretty clean. Good?

[trask]

I'd be interested in how this can work with the new ConfigProvider

it could imply polling getInstrumentationConfig()

or maybe adding a ConfigListener that instrumentations can register to listen for updates