Noah Falk noahfalk

Disclaimer: This is very much a work in progress and I haven't worked through the details or fretted over naming. The goal is to get feedback on the basics and iterate. Perhaps we'll find it is fatally flawed, but we got to start somewhere :)

Use cases

I think there are likely two different schools of thought for how people will want to use these APIs:

Ad-hoc usage - These are folks who want to add some metrics to their code with minimal effort.

Localized code changes only, ideally within a single class in a single file
Add no new types

Metrics Configuration Feature Design

This is my strawman to get discussion and feedback started. I'm actively researching and iterating on it. My overall goals with the design:

App developers can easily configure a set of metrics they want to collect and forward that data to a sink. Sinks likely, but not necessarily, will transmit the metrics out-of-process to some remote storage.
App developers should find using the API similar to configuring ILogger
3rd parties such as OpenTelemetry, Prometheus.NET, or AppMetrics can easily author a sink to capture the metrics data and transmit it.
Sink developers that understand how to use MeterListener should find this API similar and easy to adopt.
3rd party authors of instrumentation that currently takes an explicit dependency on OpenTelemetry MeterProviderBuilder should be able to easily support this API in addition.

	using Microsoft.Diagnostics.NETCore.Client;
	using Microsoft.Diagnostics.Tracing;
	using Microsoft.Diagnostics.Tracing.Analysis;
	using Microsoft.Diagnostics.Tracing.Analysis.GC;
	using Microsoft.Diagnostics.Tracing.Parsers.Clr;
	using System;
	using System.Collections.Generic;
	using System.Diagnostics;
	using System.Diagnostics.Tracing;
	using System.Runtime.InteropServices;

	using System;
	using System.Collections.Generic;
	using System.Threading;
	using System.Threading.Tasks;

	namespace SampleApp
	{
	class Program
	{
	static List<object> s_objects = new List<object>();

	using System;
	using System.Collections.Generic;
	using System.Diagnostics.Tracing;
	using System.Threading;
	using System.Threading.Tasks;

	namespace ConsoleApp19
	{

	/* We could use the new GC API witnessed during EventListener callbacks in attempt to get data from every GC.

	// Steps to run this sample:
	// 1. Create a console app and replace Program.cs with this source
	// 2. Build the app (for example with dotnet build). My exe is produced in
	// "E:\temp\EventSourceSample\bin\Debug\net5.0\EventSourceSample.exe"
	// 3. Download PerfView if you don't already have it: https://github.com/microsoft/perfview/blob/main/documentation/Downloading.md
	// 4. In an admin command prompt, run this PerfView command substituting the path to your executable:
	// PerfView.exe -OnlyProviders:MyEventSource run E:\temp\EventSourceSample\bin\Debug\net5.0\EventSourceSample.exe
	// 5. After PerfView finishes collecting, open the Events view and confirm that 1 event of type MyEventSource/HelloWorld was collected in
	// addition to the other events