Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configuration based Bytecode Instrumentation #4132

Open
Kielek opened this issue Apr 8, 2025 · 4 comments
Open

Configuration based Bytecode Instrumentation #4132

Kielek opened this issue Apr 8, 2025 · 4 comments

Comments

@Kielek
Copy link
Contributor

Kielek commented Apr 8, 2025

Feature Request

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

  • Framework or library name: any/configurable
  • Library type: any/configurable
  • Library version: any/configurable

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

Possibility to instrument method without source code modification. The goal is to have it defined in some configuration file.

Describe the solution you'd like

Mimic solution created by @johnbley for Splunk Java distribution. open-telemetry/opentelemetry-java-instrumentation#13590

Configuration methods and forma /using Otel Config/OpAMP support, will be adjusted to be more .NET friendly.

Describe alternatives you've considered

Implement feature in the Splunk distribution, but I would like to just directly donate it here.
It requires support for injecting bytecode instrumentation from plugins #2440

Additional context

It will be great to have it implemented and released withing ~3 next months.

@RassK
Copy link
Contributor

RassK commented Apr 8, 2025

The main question is to drop SDK or not to drop SDK. If you drop SDK, then you do the same thing twice.

@pellared
Copy link
Member

pellared commented Apr 8, 2025

The main question is to drop SDK or not to drop SDK. If you drop SDK, then you do the same thing twice.

Can you please elaborate? What do you mean by dropping the SDK? What things will be done twice?

@RassK
Copy link
Contributor

RassK commented Apr 8, 2025

I mean if SDK is dropped (auto inst no longer uses SDK package), there are no more issues with dependencies (almost like the alternative out-of-process-collection branch) so it could be proceeded with 'No Code' instrumentation. Which in turn means you need to implement spec (for instrumentations and exports) twice, once for manual and once for auto.

If SDK is not dropped, the 'No Code' instrumentation is very hard to be achieved. First #3896 must be resolved and proceeded with even more complicated issues.

This yaml is not only syntax sugar for byte code inst but causes you to choose between official instrumentation packages for SDK vs byte code instrumentation.

@RassK
Copy link
Contributor

RassK commented Apr 9, 2025

just adding here that I might have been confused about the 'NoCode' branding 😄
NoCode for me means after deployment experience, so no code or nuget packages.

@Kielek Kielek changed the title NoCode/Last Minute Instrumentation Configuration based Bytecode Instrumentation Apr 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants