opentelemetry-net-instrumentation

Implements OpenTelemetry tracing, metrics, and logging instrumentation in .NET codebases.

1.1k|101|Updated Nov 12, 2025
One-click install
npx skills add https://github.com/Aaronontheweb/dotnet-skills --skill opentelemetry-net-instrumentation
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: opentelemetry-net-instrumentation
Source: https://github.com/Aaronontheweb/dotnet-skills/tree/main/skills/opentelementry-dotnet-instrumentation
Command: npx skills add https://github.com/Aaronontheweb/dotnet-skills --skill opentelemetry-net-instrumentation

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Adding observability to .NET applications is error-prone: developers often add unnecessary OpenTelemetry NuGet packages to libraries, misuse ActivitySource and Meter APIs, create high-cardinality metrics, or record exceptions in ways that break backend compatibility. This Skill provides authoritative guidance for instrumenting .NET code correctly using the built-in System.Diagnostics APIs.

Core Features & Use Cases

  • Tracing with Activities: Guides correct use of ActivitySource, ActivityKind selection, span naming, status/error handling, span links, and W3C context propagation across HTTP and messaging boundaries.
  • Metrics with Meters: Covers all 7 .NET metric instrument types (Counter, Histogram, Gauge, observable variants), dimension cardinality management, naming conventions, and exemplars.
  • SDK Setup & Logs: Explains application-root SDK configuration, resources, exporters (OTLP, Prometheus, Console), sampling strategies, and ILogger integration with trace correlation.
  • Use Case: When adding distributed tracing to an ASP.NET Core order-processing service, the Skill ensures you use zero-dependency System.Diagnostics APIs in libraries, configure OTLP exporters only at the application root, and record exceptions in a way current .NET tooling can consume.

Quick Start

Ask the assistant to add OpenTelemetry tracing and metrics instrumentation to your .NET service following the built-in System.Diagnostics API patterns.

Frequently Asked Questions about opentelemetry-net-instrumentation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add OpenTelemetry tracing to a .NET application?

Use the built-in ActivitySource API from System.Diagnostics to create spans in your code, then configure the OpenTelemetry SDK at the application root with AddOpenTelemetry(), AddSource(), and an exporter like OTLP. Libraries need no OpenTelemetry packages at all.

Which OpenTelemetry NuGet packages does a .NET library need?

None. Libraries should use only System.Diagnostics.ActivitySource, System.Diagnostics.Metrics.Meter, and ILogger, which ship with the .NET runtime. OpenTelemetry packages are added only at the application composition root for collection and export.

What is the difference between Counter, Histogram, and ObservableGauge in .NET metrics?

Counter records monotonically increasing values like request counts, Histogram captures value distributions for percentiles like durations, and ObservableGauge polls a current value via callback at collection intervals, such as CPU usage. Choose based on whether the value is cumulative, distributed, or instantaneous.

Why does high cardinality cause problems in OpenTelemetry metrics?

Each unique attribute combination creates a separate time series, so unbounded values like order IDs or user emails cause cardinality explosion with excessive memory and storage use. Keep dimensions low-cardinality and make high-cardinality dimensions an explicit opt-in configuration.

Should I record exceptions as span events or logs in .NET OpenTelemetry?

Record exceptions as span events by default, since current .NET exporters, backends, and trace UIs consume span events. Support the OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN environment variable to let consumers opt into log-based or dual emission as the ecosystem transitions.

How does context propagation work across HTTP calls in .NET?

The OpenTelemetry SDK configures W3C TraceContext propagation by default, and ASP.NET Core plus HttpClient instrumentation handle injection and extraction automatically. For custom transports, use the built-in DistributedContextPropagator, which requires no OpenTelemetry packages.