Historically .NET supported emiting certain default performance counter data into the Windows Performance Counter system. On non-windows systems there is no such facility, but in its place we now have EventCounter for counters and EventPipe as an underlying transmission method. The goal is to instrument the runtime with similar counters that we had in the past, and have that data emitted via EventPipe. It is a non-goal (of this issue at least) to transmit the data to the Windows Performance Counter system.

This task tracks:

• Identify a set of runtime counters we initially want to support. We should consider what was originally supported in .NET Framework. It is OK if we start with only a high value subset, then add others later as needed. (See Vance's comments below for more detail)
• Ensure that managed wrappers exist to query the underlying data we care about. For example Process.VirtualMemorySize64 already exists whereas GC.PercentTimeInGC needs to be created.
• Modify EventCounter / RuntimeEventSource to publish counters that are backed by the APIs.

Proposed list of runtime counters for .NET Core 3 (see https://github.com/dotnet/diagnostics/issues/83#issuecomment-446729009):

System Counters

• Working set memory
• CPU
• Handles

Exception performance counters

• Exceptions thrown

Thread performance counters (see https://github.com/dotnet/corefx/issues/35500)

• Threads
• TPL threads
• Total queue length
• work items processed
• Lock contention

Memory

• Bytes in all heaps
• Gen 0/1/2 collections
• % time in GC
• Gen 0/1/2 and LOH size
• Allocation rate

JIT

• IL bytes Jitted

Loader

• Number of Assemblies currently loaded