Instrument adapters to identify usage in apps

[twsouthwick]

Summary

By instrumenting the adapters users can identify what the adapter usage looks like in their application given their actual loads.

Motivation and goals

Once a user has migrated their project to ASP.NET Core but is still using the adapters, it would be nice to understand how much of the adapters are being used and what the cost will look like to migrate off of them. By instrumenting the adapters with diagnostics that surface information about usage, a user can collect data and identify what their reliance on the adapters look like.

The main goal behind in providing the adapters is that it is difficult to move off of them while running on ASP.NET framework. The adapters have a bit more flexibility while running on core to provide insights into their usage than could be obtained on framework. Because System.Web itself is essentially frozen and not serviceable, this kind of information would be difficult to instrument there. However, the adapters can provide this and will help identify what is actually being used.

In scope

We should use the types in System.Diagnostics.Activity to instrument code that can then be sent to wherever a user may be sending their personal telemetry. This can be AppInsights or any other service of the sort. By using the these types, we can be agnostic to what the service looks like, but provide information that could be useful.

We should emit an activity for each of the middlewares we provide to measure their impact and understand their usage:

• SessionMiddleware
• PreBufferRequestMiddleware
• BufferResponseMiddleware
• Additional ones as they are added

To understand how much a code base may be accessing the adapters, the events that would be helpful to emit on each access:

• HttpContext.Current
• HttpContext.Items
• HttpContext.Request
• HttpContext.Response
• HttpContext.Cache
• HttpContext.Session

Other potentially useful items:

• Emit an event for each session key that is retrieved or added

Out of scope

We don't want to go to fine-grained on this as emitting the events has a cost, even if the activity source is not available. Starting with the high level events of general usage and soliciting feedback on if there's others that make sense.

Risks / unknowns

We would want to minimize any data being exposed beyond what is necessary due to privacy concerns.

Examples

This would be hooked up as any OpenTelemetry would (see https://devblogs.microsoft.com/dotnet/opentelemetry-net-reaches-v1-0/ for details). Once hooked up, a trace for a request will provide information that can be analyzed using industry tools. An example where the data is funneled into Zipkin is shown below: