Configuration based instrumentation - POC

[Kielek]

Why

POC for #4132

What

Possibility to instrument any method with <=9 o parameters by injecting configuration by the file.
To make the review easier and split discussion about file format separate I hardcoded some examples separately.

Performance - if we decide to keep code directly in the main project, we could avoid playing with method name fetching and pass it from the native code.
Documentation + Changelog

Topics not covered, raised on Java side:

• How to enable such configuration, is it enough to have one switch to this (lack of configuration)? Alternatively, we could have plugin to contains all this stuff.
• Possibility to setting up static span-attributes,
• Possibility to setting up static span-kind,
• Possibility to calculate span-name, span-kind, and span-attributes dynamically. Some evaluator is needed to avoid security issues.

Warning

It will be not working for inlined methods.

Tests

CI + Added new

Checklist

• CHANGELOG.md is updated.
• Documentation is updated.
• New features are covered by tests.

[RassK]

Seems very security concerning feature for me even by having it off by default.

Just an idea, that the config could be signed and verified by a cert installed to trusted store.

[nrcventura]

I think that this approach is reasonable and can help with scenarios where you just need a span created with some constant parameters applied to that span (kind, name, attributes, etc.). It provides an alternative to needing to update the code to create spans.

This solution can fall short if context propagation headers need to be extracted or injected. So this approach should not be used for entry points into a service that are part of a distributed system. To make that work, we need some way to declaratively specify how to extract the tracing context prior to creating the span. Similarly we would need some way declaratively define out to inject the headers.

Looking through this POC, I do not know how well async methods are handled (those returning a Task or ValueTask). Is that something automatically handled, or does each instrumentation need to manage the lifecycle of the activity differently based on the return type?

We should discuss which uses cases we're trying to solve for with the configuration based instrumentation approach.

1. Allow the DevOps persona to add more details to a trace by creating more spans within that trace?
2. Allow vendors to declaratively extend the available instrumentations out of the box without needing to maintain additional instrumentation packages?
3. Allow the DevOps persona to add NoCode instrumentation to a library that does not have existing OpenTelemetry instrumentation?

This approach seems valid for use case 1, but the other use cases likely require significantly more work.

[brsmith080]

For most of the applications in our environment we use newrelic's dotnet agent https://github.com/newrelic/newrelic-dotnet-agent for instrumentation. I believe this change would let us achieve something like this https://docs.newrelic.com/docs/apm/agents/net-agent/custom-instrumentation/create-transactions-xml-net/?

if so, that would be great. We use this a lot from the newrelic agent and is one of the question marks we have while looking into moving off of the newrelic agent and its api and onto open telemetry across the board.