.NET developer experience survey

[samsp-msft]

• differences from upstream spec:
  • discrepancies - why?

• .NET has lower level APIs for Logging (ILogger), Metrics (Meter), Tracing (Activity/ActivitySource)
• Much of this is covered by https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md
  • should review this list again
• .NET doesn't have a good implementation of context/baggage API, having a baggage span processor

• extra convenience
  • Typically try to keep to the spec, and not have extra [convenience] functionality specific to .NET, if it's not in the spec it goes in the contrib repo.
  • Integration with Hosting APIs in .NET which are convenience mechanisms for configuring .NET
  • UseOtlpExporter - simple way to add OTLP for logs/traces/metrics in one API call
  • MetricsBuilder (.NET runtime) enables specifying metrics to listen to based on .NET config files
  • Have to explicitly configure which spans to listen to telemetry for (eg. microsoft.aspnet.*)

• Most requested features
  • API
  • SDK

• Spec says to always create a spanID - which would mean creating Activities in .NET for each sub operation - as that is a high expense. .NET only creates a root so we have a TraceId/SpanId. (.NET is out of spec compliance because of this, but don't see this as a user issue)
• Where to put a Durable ID for LogRecord - so backends can drop spammy log messages
• Better way to decorate metrics with context - what is the equivalent of a span processor for metrics
  • Carry-on baggage - adding additional data to a context that is propagated to each span to in the context.
  • Ability to define a scope and then all spans/logs within the scope will include its baggage
• No good way to designate a node as ingress and to ignore all context on requests that come into that node

• Instrumentations/semantic conventions

• (sarcastic) when will they be stable?
• Instrumentation libraries can't be marked as stable as the corresponding conventions are not stable

• things to consider from other telemetry projects

• Some of the Java agent lifecycle extensions should be part of the common spec

[stevejgordon]

One possible but non-obvious thing I experienced personally is stopping a span from being recorded after the sampling decision. The context for this scenario (and example code to solve it) is in this comment. Potentially, this would be useful as an extension method for Activity.

[matt-hensley]

As a follow-up on my Java extension comments from the .NET SIG, the "zero code" instrumentation does have a plugin interface. It's not as complete as what's available in Java but useful to mention.