-
Notifications
You must be signed in to change notification settings - Fork 762
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
New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API part 3 #2256
Conversation
src/OpenTelemetry.Instrumentation.AspNet/Implementation/AspNetInstrumentationEventSource.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
{ | ||
return uri.ToString(); | ||
activity.SetStatus(Status.Error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cijothomas @alanwest Check this out. In the case of exception thrown when !activity.IsAllDataRequested
I thought we should still at least mark the status as Error
. What you guys think about that?
I'll do the same for AspNetCore if we all agree this is desired:
opentelemetry-dotnet/src/OpenTelemetry.Instrumentation.AspNetCore/Implementation/HttpInListener.cs
Line 267 in 0959e56
public override void OnException(Activity activity, object payload) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up removing this. Turns out anything with !activity.IsAllDataRequested
isn't fed to the processor(s) so it seemed kind of pointless to do.
8b1fd83
into
open-telemetry:aspnet-telemetrycorrelation-otelintegration
…e + OpenTelemetry.API (#2270) * New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API. (#2249) * New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API part 2 (#2254) * Use a single context.Items key for state management to make things more efficient. * Added a comment for clarity. * Code review. * New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API part 3 (#2256) * Update ASP.NET instrumentation to use the new TelemetryHttpModule. * Fixed TelemetryHttpModule not starting its Activity objects. Added an example of request suppression. * Tweaks an logging improvements. * Sealed AspNetInstrumentationEventSource. * Code review. * New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API part 4 (#2258) * Fixed up TelemetryHttpModule unit tests. * Added tests for the new HasStarted helper and added checks for StartedButNotSampledObj when not sampled. * Code review. * New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API part 5 (#2261) * Updated ASP.NET instrumentation tests for new TelemetryHttpModule. * Added a test for the new RecordException option. * Code review. * New design for TelemetryHttpModule using ActivitySource + OpenTelemetry.API part 6 (#2264) * CHANGELOG & README updates. * Apply suggestions from code review Co-authored-by: Reiley Yang <reyang@microsoft.com> Co-authored-by: Reiley Yang <reyang@microsoft.com> * Lint + sanity checks. * Lint attempt 2. * Restored CHANGELOG changes lost in merge. Co-authored-by: Reiley Yang <reyang@microsoft.com>
Relates to #2249
Changes
Notes & interesting lessons learned
Turns out there is no single instance of HttpApplication and HttpModules aren't singletons. Check it out:
https://github.com/microsoft/referencesource/blob/5697c29004a34d80acdaf5742d7e699022c64ecd/System.Web/HttpApplicationFactory.cs#L67-L71
There are two different bags of HttpApplications. The "special" ones are for application-level events (ex Application_Start). The "free" ones are created/re-used for each request and are sent request-level events (ex Begin_Request). This makes it much more difficult than I anticipated to find the TelemetryHttpModule and attach callbacks for instrumentation. I ended up just adding a static for the options. Not the most elegant solution but probably the least code. We could try to hook into HttpApplicationFactory with reflection and monkey patch in some code to call us anytime an HttpApplication is created/re-used.