NameResolutionTelemetry event source provides average dns lookup time, which is not very informative

[HolyPrapor]

An average time is misleading in a lot of cases because one is unable to see spikes of load.

Unfortunately, .NET NameResolutionTelemetry does not calculate informative percentiles nor it has a way to calculate those because underlying stop/fail events do not have a stopwatch (or at least hostname) to calculate latency.

I understand that underlying counters do not calculate percentiles because it's expensive and calculate average instead. (It's better than nothing)

But as far as I can see, it is very easy to add this info to events so that one could calculate whatever he needs.

Would you consider this proposal?

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

An average time is misleading in a lot of cases because one is unable to see spikes of load.

Unfortunately, .NET NameResolutionTelemetry does not calculate informative percentiles nor it has a way to calculate those because underlying stop/fail events do not have a stopwatch (or at least hostname) to calculate latency.

I understand that underlying counters do not calculate percentiles because it's expensive and calculate average instead. (It's better than nothing)

But as far as I can see, it is very easy to add this info to events so that one could calculate whatever he needs.

Would you consider this proposal?

Author:	HolyPrapor
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

[MihaZupan]

The NameResolution telemetry will emit Start/Stop pairs for each resolution.

The events will be fired from within the same async scope and can as such be correlated (an AsyncLocal created during Start will be visible during Stop).
From this, you can get the time taken for a specific operation by calculating the difference between the event timestamps, or calculate any other statistic you are interested in.

For an example, see https://gist.github.com/MihaZupan/ba499563e5d602d990872fd9f5c35229 that is making use of the Yarp.Telemetry.Consumption package (it can be used outside of YARP). The sample does correlation for Kestrel events, but then pattern is the same for name resolution.

[MihaZupan]

That said, if there are some statistics that would be useful to include in counters for multiple users, we would certainly consider it - one such discussion is going on in #48885

[jkotas]

The events will be fired from within the same async scope and can as such be correlated (an AsyncLocal created during Start will be visible during Stop).

AsyncLocals work only if you are consuming the events in-proc.

@MihaZupan Is it possible to correlate the events in out-of-proc listener? Out-of-proc listeners are very common in telemetry solutions.

[MihaZupan]

Is it possible to correlate the events in out-of-proc listener?

Yes. If you enable the TplEventSource with the TasksFlowActivityIds keyword, other EventSource events will also contain an ActivityID. The activity ID is also tracked as an AsyncLocal by ActivityTracker and it encodes an async scope hiearchy.

An example with PerfView using *System.Net.Sockets,*System.Net.NameResolution,*System.Net.Http,*System.Net.Security,System.Threading.Tasks.TplEventSource:0x80:4:

[karelz]

Triage: Seems to be addressed - solution does exist. Closing.