Profiling/observing the middleware chain

[avanderhoorn]

We and other profiling/debugging groups/teams/projects have the need to be able to observe the ins/outs of each middleware in the chain as its excited. Previous attempts at this required each listener to replace the default app builder and wrap/modify the middleware. This is fragile and breaks down when multiple observers are in play.

This hook/event/notification should also make available the HttpContext, so if specific consumers want to observe changes that middleware makes to the context it can. Additionally, it should make available contextual details that the middleware can opt into providing (specifically, a meaningful name and any other data the middleware want to make available to consumers - for instance settings, config, decisions, etc).

Pretty much across the board, this is the top request we have from users when speaking about what they want to see when creating vNext apps.

Had this discussion with @davidfowl @rynowak @anurse @lodejard @nikmd23

[avanderhoorn]

Bump @Eilon @muratg. Note this has been designed by @davidfowl and @lodejard.

[muratg]

cc @Tratcher

[Tratcher]

@davidfowl @lodejard Your design details were never captured. We need to meet up and re-hash them.
/cc: @glennc

[avanderhoorn]

For my part, the general concept was that we, the user or any other interested parties could "touch" a given point which would setup the one "ProfilingAppBuilder" (the idea being to avoid having multiple ones registered at the same time). This build would then be responsible for wrapping any of the middle that was registered... this wrapper would then publish Diagnostic Source events for the in's and out's of any of the middleware.

Besides just raw timing data, part of the trick was also to try and get a meaningful name out. We had discussed that this could be done by convention and any middleware author could opt to have a name given to their middleware. Exactly how this was done, wasn't exactly settled but we had talked about maybe using HttpContext.Items to flow a middleware context which authors could look for. This mechanism would as allow authors to provide other ad hoc context data that could be useful for debugging/diagnostics purposes... like the result of what the FileServerMiddleware served up, etc.

[muratg]

@glennc Can you schedule a meeting to finalize the design here? @avanderhoorn and @davidfowl already met before and had a sketch for a design, but let's get it decided on and written down.

[avanderhoorn]

@glennc @muratg Just wondering if there are any updates on this one?

[muratg]

@avanderhoorn Unfortunately we haven't yet had a meeting to close on the design.

cc @davidfowl