Dotnet-counter and other tools for specifying meter and ActivitySource names should support namespace wildcards

[samsp-msft]

Meter and ActivitySource have a name that typically needs to be registered with whatever tool is being used to monitor the telemetry. Currently the whole name needs to be registered, which is going to be onerous when it comes to large apps with a number of counters.

Logs uses a namespace style naming scheme, which enables a simplification of configuration as you can use a shortcut to set a log level for all items under that namespace and its descendants. We should use a similar approach with Meter and ActivitySource, and recommend an a.b.c style naming scheme, so that listening tools can use prefix matching to select the namespaces that will be tracked.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[samsp-msft]

@noahfalk

[noahfalk]

The "and other tools" makes the scope of this issue unclear. As a generalized goal for better usability I have no opposition, but as an issue that tracks a specific set of work that we'd like to mark complete at some point we need to decide which tools are in scope :) How about we use this issue to track dotnet-counters only?

In terms of the actual design, the big open question for me is what happens when the wildcard matches too many time series? There are two major limits I am aware of:

• Limits on console UI rendering space - typically would allow 30-100 time series to be in view
• Limits on in-proc memory - MetricsEventSource has default limits at 1000 time series and 100 histograms

dotnet-counters needs to decide which time series to include within the limits and how do we expect the user to respond if the portion of results returned from the wildcard search isn't the portion they care about?

[samsp-msft]

My plan is to link in issues for other tools / repos, based on deciding a pattern here. I don't know how much of this is documentation and patterns that all related tools need to implement - or base layer functionality as part of the APIs.

[noahfalk]

I don't know how much of this is documentation and patterns that all related tools need to implement - or base layer functionality as part of the APIs.

If we were doing this in dotnet-counters I assume we'd implement it by subscribing to the InstrumentPublishing event on the MetricsEventSource, enumerating all instruments as they were created and determining at the UI layer which of those discovered Meters/Instruments matches the wildcard. If the wildcard matching is only used to print matches we'd print the names and be done. If we are trying to combine wildcard matching with a view that is expected to display live metric values and then as-needed dotnet-counters should update the configuration on the EventPipe session to tell MetricsEventSource to send data for whichever Instruments matched. We also need heuristics to determine which meters get tracked and displayed when the total set of matches exceeds screen space or tracking limits.

Next we need a 2nd solution to handle EventCounters such as an EventCounter->Meter automatic bridge, manually creating parallel Meter instrmentation for existing EventCounter instrumentation, building new enumeration capabilities for EventSource and EventCounters from scratch, and/or deciding EventCounters aren't going to be supported for wildcard matching.

On the documentation side currently our docs recommend the assembly name as a hierarchal Meter name. We might want to change that to namespace instead, but its should be fairly usable even as-is.

If we are talking about dotnet-monitor or VS the story is probably similar. Anything that bridges EventCounters->Meters or adds parallel Meter instrumentation in-process could be work shared by all tools. The logic of doing the wildcard matching, deciding which Meters to track, and rendering the data back to UI or network streams probably wouldn't get shared. dotnet-monitor and VS don't have the console UI space limitations, but they would still have to contend with MetricsEventSource tracking limits.

[ghost]

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

Issue Details

---

`Meter` and `ActivitySource` have a name that typically needs to be registered with whatever tool is being used to monitor the telemetry. Currently the whole name needs to be registered, which is going to be onerous when it comes to large apps with a number of counters. Logs uses a namespace style naming scheme, which enables a simplification of configuration as you can use a shortcut to set a log level for all items under that namespace and its descendants. We should use a similar approach with Meter and ActivitySource, and recommend an `a.b.c` style naming scheme, so that listening tools can use prefix matching to select the namespaces that will be tracked.

Author:	samsp-msft
Assignees:	-
Labels:	`enhancement`, `area-System.Diagnostics`
Milestone:	9.0.0