Skip to content

Instantly share code, notes, and snippets.

@noahfalk
noahfalk / README.md
Last active July 21, 2023 02:33
Metrics configuration feature design

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.

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:

  1. 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
@noahfalk
noahfalk / Program.cs
Created May 8, 2021 01:17
Create and collect ETW events from a custom EventSource
// 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
@noahfalk
noahfalk / Program.cs
Created May 19, 2020 06:42
Witnessing the new GC API in the callbacks for EventListenever GC events
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.
@noahfalk
noahfalk / gist:82cc9fc6c1a2ae0ac2e189bb317a6c7e
Created May 19, 2020 05:22
Sampling the new GC API to get periodic reports of fragmentation
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>();
@noahfalk
noahfalk / Program.cs
Created May 19, 2020 02:21
Monitoring fragmentation with EventPipe
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;