OpenTelemetry NET Instrumentation

If you're adding OpenTelemetry to a .NET codebase, this skill helps you get the instrumentation right. It covers the practical stuff: ActivitySources, spans, metrics, naming conventions, and how to avoid tanking performance with telemetry overhead. Built by aaronontheweb, who knows the .NET observability space well. The guidance is especially useful if you're exposing telemetry as part of a public API, where you need to think through stability and design. With 981 GitHub stars and passing all security audits, it's a solid reference when you're beyond basic traces and need to instrument production code properly.

skills.sh installs: 431
GitHub stars: 1.3K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add aaronontheweb/dotnet-skills --skill OpenTelemetry-NET-Instrumentation --agent claude-code

Installs into .claude/skills of the current project.

Files

OpenTelemetry .NET Instrumentation Skill

When to Use

Adding OpenTelemetry instrumentation to .NET code (traces, metrics, logs)
Creating or modifying ActivitySources, Meters, or ILogger usage
Setting up the OpenTelemetry SDK, resources, exporters, or sampling
Reviewing telemetry implementations for spec compliance
Optimizing instrumentation performance
Designing telemetry APIs that become part of the public surface
Implementing context propagation across service boundaries

Architecture: .NET Is Different

CRITICAL: The .NET OpenTelemetry implementation is fundamentally different from other platforms. .NET provides tracing, metrics, and logging APIs in the framework itself. That means OTel does not provide a separate instrumentation API — it uses the built-in .NET APIs and acts as the collection/export layer.