Support additional perf counter providers

[roji]

• Extends infrastructure to allow specifying arbitrary number of perf counter providers.
• Add support for Kestrel and Npgsql counters.

Closes #1513

Hopefully the perf counter settings I set make sense... to be tested more thoroughly.

/cc @sebastienros @shirhatti @davidfowl

[davidfowl]

This is excellent 😄

[sebastienros]

How should we make it truly extensible? Or should we even care?
Here we are enlisting npgsql directly. I think it's ok for aspnet/runtime, but what for other libraries?

Counters are special, as they can't be added from the application itself, but on the agent. Maybe we could have some arguments on the driver that would point to a file that contains these counter metadata, and then instead of passing a string like you did here, we could just send the metadata directly with the job. After all the metadata is already contained in the ServerJob object when it's added from the agent. So if any metadata is set when the job is sent, then the agent would just read it too. We can still embed predefined sets (aspnet/runtime/npgsql/...) in the driver.

[davidfowl]

Wait I thought this let you specify event source names

[roji]

Yeah this lets you specify event source names (e.g. System.Runtime, Microsoft-AspNetCore-Server-Kestrel, Npgsql), but the infrastructure reduces all perf counter samples it takes (e.g. average, max), so it needs some metadata to tell it what to do.

We could just perform the various possible reductions for all counters (average, median, max) and output all of them...

[sebastienros]

Yes, but without metadata you don't see it in the console. For instance imagine you track the aspnet number of requests. It's a counter that always increases. We can track it continuously but how does the driver know what to "record" in the results: max? avg? last? That's why we have metadata.
Or we could just not display anything in this case but keep tracking all the measures. Though I am not sure how useful it would be.

So in the end I think it's better to have some string that represent sets event counters, including the mask the represents the source to listen to.

[sebastienros]

@roji that's a good idea, at least for the ones that are not described. Or generate these metadata for those which don't have any.

[roji]

Could even display all reductions always, doesn't hurt... will open an issue to track.

[sebastienros]

Wait, I need to revert your change, you modified the identifier which will break all charts.

[sebastienros]

Or are you ok if I put the old values back?

[roji]

You mean the name in MeasurementMetadata? Sure, put the old values back, there's the source which identifies where it came from anyway.

[roji]

#1534