User Story: .NET developers have a first-class experience for observability using Open Telemetry in their applications

[samsp-msft]

Applications need to be able to easily implement the 3 pillars of observability:

• Logging
• Metrics
• Distributed Tracing

And egress those artifacts to appropriate storage and analysis environments so that SRE can monitor the health of the service, and ideally be able to detect and rectify issues before they have an adverse effect on the service's customers.

The industry is moving from having vendor specific monitoring solutions to using a common standard - Open Telemetry.
.NET is different from most other languages in that we provide APIs for applications to use to provide telemetry data as part of the platform, specifically ILogger, EventCounter / Meter & ActivitySource / Activity. Applications don't need to take a dependency on a vendor specific SDK, they can use the APIs directly from the platform to provide instrumentation. The OTEL SDK sits on top of the .NET APIs and collects the telemetry information and makes it available to egress providers which know how to talk to specific back ends.

For applications where the operator doesn't or can't modify the application code to enable telemetry, we need to have a solution for being able to collect and egress the information. Dotnet-monitor is ideally suited to being usable in those scenarios as it already has the out-of-band communication mechanism for .NET processes, and has collection rules for logs & metrics. It needs some changes to be better suited for continuous monitoring and egress providers to be able emit the data using OTLP, which is the open-telemetry protocol.

This User story includes:

• Simplify the initial development experience for the OpenTelemetry SDK Azure/azure-sdk-for-net#33865
• What is the future for dotnet-counters list? #3626
• Advancing Metrics in .NET #4083
• Implement/Convert existing EventCounters to Metrics runtime#79371