Make bytecode instrumentation user-extensible

[tchowice]

Feature Request

Are you requesting automatic instrumentation for a framework or library? Please describe.

• Framework or library name : OpenTelemetry.AutoInstrumentation

Is your feature request related to a problem? Please describe.
The .NET AutoInstrumentation agent supports bytecode instrumentation, but this support is currently entirely contained in the AutoInstrumentation itself and does not appear to support user extension. If a user has a internal legacy library that they want to instrument without having to modify the library code, the only way to bytecode-instrument said library is to fork the opentelemtry-dotnet-instrumetation repo, write their own bytecode instrumentation code (via the [InstrumentMethod] attribute), and compile their own copy of the AutoInstrumentation agent, which is highly inconvenient.

Describe the solution you'd like
We would like to see extensibility added to bytecode instrumentation. This extensibility could be implemented in one of the following two ways, or both:

• Users are able to write their own libraries with [InstrumentMethod] attributes, and define their own integration names. The AutoInstrumentation agent can then be configured to look for these libraries and load up the custom bytecode instrumentations defined within.
• Users are able to define the autoinstrumentable methods in a JSON/YAML configuration file. The file would define the classes/methods to instrument, and which spans/metrics to create when the methods are called. The AutoInstrumentation agent reads the configuration file instrument the configured methods.

[Kielek]

@tchowice, could you please tell us more about your needs? Do you have any specific method/libraries in mind to be instrumented? Do you think that it will be valuable for the whole community?

Speaking directly to your request:

1. InstrumentedMethod attributes are use to manage the list of bytecode instrumentation in the convenient way. It is not needed to be propagated outside this repository. It is strongly integrated with SourceGenerator. In fact what you need, is to provide Payload in your Plugin. You can find example here.
2. To make it possible, we need to agreed on the public contract between AutoIsntrumentation and Plugins. For now, it is only available for testing purposes. There were no requests so far for external usage.
3. I do not think that parsing JSON/YML is the safest option. It should not be done by typical users as it require pretty deep understanding both for .NET and this project.

Would you like to contribute some changes?
If so, you could create draft PR and/or join our next SIG meeting.