Add Dns event counters

[stephentoub]

We should consider adding some event counters around name resolution, e.g.

• Number of Dns requests issued
• Number of Dns requests currently in fight
• Number of unique Dns requests currently in flight

[ghost]

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

Issue Details

---

We should consider adding some event counters around name resolution, e.g.

• Number of Dns requests issued
• Number of Dns requests currently in fight
• Number of unique Dns requests currently in flight

Author:	stephentoub
Assignees:	-
Labels:	area-System.Net
Milestone:	6.0.0

[MihaZupan]

Right now we have

• dns-lookups-requested - DNS Lookups Requested (total counter)
• dns-lookups-duration - Average DNS Lookup Duration

Number of Dns requests currently in fight

Something like current-dns-lookups seems reasonable - we have that for Net.Security and Net.Http as well.

With #48566 in mind, the meaning of this would likely be "number of not-finished Dns.Foo(...) calls".

Number of unique Dns requests currently in flight

I assume the tracking of "unique" would be duplicated between the Telemetry impl and a potential #48566 impl?

[stephentoub]

dns-lookups-requested

Ah, I didn't see that one. That's the "Number of Dns requests issued" I was asking for.

Something like current-dns-lookups seems reasonable ... the meaning of this would likely be "number of not-finished Dns.Foo(...) calls"

Yes, if we're already tracking number of requests initiated, then if we also tracked number of requests finished, it would be the difference.

I assume the tracking of "unique" would be duplicated between the Telemetry impl and a potential #48566 impl?

There might be some duplication, but whatever we do for #48566 is likely to only apply to a portion of requests, e.g. those that are implemented by queueing work items to the thread pool. On Windows most if not all requests will instead be implemented with async OS functionality, and we wouldn't do any such uniqueness tracking for the implementation. Longer term, we'd expect that to be true for all OSes.

[ManickaP]

Triage: shouldn't be hard to implement, the numbers might be useful. We would want current-dns-lookups for 6.0.

[MihaZupan]

Currently implemented:

• Start/Failed/Stop events
  • Failed could use some additional info such as the exception message - right now it's just an empty event
• dns-lookups-requested (total for process)
• current-dns-lookups (current)
• dns-lookups-duration (average time taken for lookups within the last counter period)

Not yet added:

• Number of unique DNS requests currently in flight

Potential:

• Number of unique DNS addresses resolved in an application’s lifetime (from Additional diagnostics for .NET 6 #56072)

[karelz]

Taking the discussion from #56072 (comment) here:

How many unique DNS addresses are resolved in an application’s lifetime?

What is a developer going to do with this information? Doing this "perfectly" would be a leak, as it would require the application to maintain a set of every address it saw; that's not viable (it'd be like Kestrel having a counter for how many unique client addresses connected to it over the process' lifetime). Events are already emitted for that information, so a dev can post-process that information from traces if needed. #48885 (this issue) proposes one for the number of unique addresses currently being resolved; from my perspective, that's more reasonable, though I'm not sure how actionable it actually is, either.

We should answer:

1. Do we want current vs. app-lifetime counter?
2. How is it useful to end users?
3. Is it important for 6.0?

@davidfowl can you respond here please to @stephentoub's comment above?

Moving the issue to 6.0 to make decision what to do in 6.0.

[danmoseley]

There are ways to get a statistical estimate of the number of unique addresses with quite limited storage.

https://stats.stackexchange.com/questions/19014/how-can-i-estimate-unique-occurrence-counts-from-a-random-sampling-of-data

https://en.wikipedia.org/wiki/HyperLogLog?wprov=sfti1 (there is a relatively simple C# implementation with Apache license that could be used.

https://en.wikipedia.org/wiki/Count-distinct_problem?wprov=sfti1

Etc

[geoffkizer]

Events are already emitted for that information, so a dev can post-process that information from traces if needed

+1. Let's log data at runtime and do statistical analysis in post-processing.

[karelz]

Moving it to 7.0. @davidfowl let us know if you have more info that should change our mind ...

[danmoseley]

@davidfowl can you ack or push back here to help us make the right call?

[davidfowl]

Is there any low hanging fruit here we could tackle for .NET 6? I think the unique dns requests are difficult and we can punt for now, but it would be ideal to add some of the other counters.

[MihaZupan]

The "Number of unique DNS requests currently in flight" counter doesn't seem critical for 7.0. Moving to future.

but it would be ideal to add some of the other counters

@davidfowl did you have any other counters in mind (aside from those mentioned in #48885 (comment))?

[davidfowl]

This is something I would like to get done for .NET 8 now that we're moving to metrics. Specifically, a Meter in System.Net that reports the number of DNS resolutions with a host name dimension.

[antonfirsov]

@davidfowl is DNS the only area you find critical in .NET 8 to define Metrics for, or is there anything from #88383 and #88384 you want us to get done?

[davidfowl]

HTTP counters: #88384 and DNS counters are the most important. The socket and TLS ones I think can wait. Specifically, the counters you cannot write yourselves are the most important for us to add (the connection pooling data that exists inside of SocketHttpHandler's guts).

[antonfirsov]

That should be all covered by #84978, #88384 is mostly about extras.

[davidfowl]

Perfect, then I think the DNS one is the next most important one to add that isn't currently tracked for .NET 8.