Allow purely managed instrumentation libraries to be loaded through CLRIE

[alex-fedotyev]

This is inspired by @SergeyKanzhelev 's work on adding instrumentation to the methods using .NET based decoration. http://apmtips.com/blog/2016/11/18/how-application-insights-status-monitor-not-monitors-dependencies/

It would be great to be able to do something similar and leverage CLRIE to create a managed only definition of what needs to be instrumented. Is this something that you are planning by any chance?

[SergeyKanzhelev]

CC: @pjanotti

@alex-fedotyev, thank you for your interest! I agree that having pure-managed code instrumentation would be the best way to go in future.

There are a few logistical questions we haven't discussed internally yet:

• will we keep the current approach with the Intercept nuget package or this feature should be built-in into CLRIE
• will the Intercept be developed and distributed as part of this repo (as Microsoft) or as OpenTelemetry
• what's the right brand/name for the Intercept as currently it's branded as Application Insights.

If you have comments on your preferences - please comment here.

[alex-fedotyev]

That sounds great!

IMO technology to apply instrumentation using managed or unmanaged approaches isn't linked to OpenTelemetry, even likely it would be one of the main use cases. This looks more like a proper part of CLRIE functionality, which would allow developing "managed profiler extensions".

[pjanotti]

Finally, I'm having a look at the CLRIE and the Intercept Extension.

First just to make clear that we are discussing the options for OpenTelemetry .NET Auto-Instrumentation here. Some of my initial takes below:

will we keep the current approach with the Intercept nuget package or this feature should be built-in into CLRIE

One of our goals is to have zero-touch instrumentation, that points in the direction of building a CLRIE InterceptionMethod that can load multiple managed "instrumenting" libraries as @alex-fedotyev asked. That said I guess that the InterceptMethod can simply have a list of managed modules to load and on the initialization of those run any needed managed code.

Regarding location/branding the "generic" parts can be under Microsoft or .NET Foundation, the specific instrumentations/intercepts should be under OpenTelemetry.

I'm a bit worried about the timeline to get this started on CLRIE comparing to the alternative of starting with the DD implementation. Of course, that is not the only factor but it should be taken into account too. Ideally, this will be as close as possible to the OpenTelemetry releases.

[weltkante]

I don't know how flexible you want to be, but I'm looking into profiler based mocking as a technique to make static methods / seled classes / nonvirtual methods replacable so you can do unit testing without compromising your public API or hardcoding internal hooks everywhere.

Its requirements are very close to what Application Insights / Intercept Extension does, but not exactly identical. You want to override the implementation of a method and calculate a return value (or throw an exception), preferably conditionally so you can still let the original method run if you decide to do so (for mocking individual instances). Support for ref/out parameters is required because if you calculate return values you need to calculate and modify those as well.

I'm still prototyping the CLRIE extension though. Just adding it here as another usecase since its very close but not identical to the logging/telemetry usecase.