[Comment] Optimally Configuring Open Telemetry Tracing for ASP.NET Core

[RehanSaeed]

trafficstars

https://rehansaeed.com/optimally-configuring-open-telemetry-tracing-for-asp-net-core/

[ZedZipDev]

Hi, thank you for the great article! One question. I have multiple c# applications: NET Core, legacy WinForms apps. Is it possible to use OpenTelemetry in WinForms apps? How to?

[RehanSaeed]

Hi, thank you for the great article! One question. I have multiple c# applications: NET Core, legacy WinForms apps. Is it possible to use OpenTelemetry in WinForms apps? How to?

You certainly can. With ASP.NET Core, there are packages which setup some basic telemetry for you. With desktop apps, you'd have to do all that yourself. Take a look at my first blog post in the series, that should be enough to get you going.

[bmcclory]

Your example Enrich function demonstrates reading HttpContext.User during the "OnStartActivity" callback, to attach "enduser" attributes (or tags) to the Activity. A couple questions about this:

• "OnStartActivity" executes very early in the ASP.NET Core request pipeline, long before application authentication middleware has executed. I believe the User principal will always be anonymous at this point.

• It'd probably work correctly if you read User during the "OnStopActivity" callback instead, but...

• The Open Telemetry specification recommends propagating "enduser" attributes via the Baggage mechanism:

These attributes describe the authenticated user driving the user agent making requests to the instrumented system. It is expected this information would be propagated unchanged from node-to-node within the system using the Baggage mechanism. These attributes should not be used to record system-to-system authentication attributes.

A real-world scenario: An end user authenticates with a front-end ASP.NET Core application, which invokes multiple backend systems using application credentials. The "enduser" details for those backend spans should be the original end user (propagated via Baggage) and not the front-end application's client ID.

Now we have a conundrum. "OnStopActivity" is too late in the request execution to meaningfully attach Baggage to an activity -- the activity is already (nearly) complete and that Baggage won't be propagated. But "OnStartActivity" is too early to resolve the enduser details!

I think the solution here is to manage "enduser' Baggage somewhere else -- outside of this Activity Enrich callback. Probably a middleware component that runs immediately after Authentication.

In a system where all end-user traffic flows through a gateway, that's likely the only place that needs such a middleware. Backend ASP.NET Core apps (behind the gateway) might enrich all their Activities with that Baggage data -- e.g. using a generalized EnrichingProcessor like this OTEL .NET sample -- rather than only enriching the activities produced by the AspNetCoreInstrumentation.

But I'm pretty new to all of this and am still just getting started with OTEL...

[RehanSaeed]

@bmcclory I wrote that extra bit of extra code for illustration but I think you're right, we'd need to use a filter to add tags or baggage. I'll update my post to remove that bit of code.

[bmcclory]

Sounds good. Great blog series by the way -- was one of the first places I landed when I began my journey into OTEL .NET and was an excellent orientation. Thanks!

[RehanSaeed]

Thanks @bmcclory. This is another excuse for a new post.