Skip to content
Purview Dev logo

Telemetry SourceGenerator

Stable

Interface-based telemetry for .NET with zero boilerplate.

activity c-sharp distributed-tracing dotnet events high-performance-logging instrumentation logging melt metrics nuget observability open-telemetry open-telemetry-csharp otel roslyn source-generator spans telemetry tracing
Source code Star on GitHub 36 Documentation llms.txt Releases Issues
NuGet version of Purview.Telemetry.SourceGenerator NuGet downloads of Purview.Telemetry.SourceGenerator Build status of Telemetry SourceGenerator

The problem

A source generator that turns simple interface methods into OpenTelemetry-aligned Activities, structured ILogger logging, and Metrics. Define telemetry once on an interface; the generator emits the implementation, DI registration helpers, and multi-target generation — no runtime reflection, no boilerplate.

From the repository

.NET source generator for interface-based telemetry. Generates OpenTelemetry-aligned Activities, structured ILogger logging, and Metrics from interface methods with zero boilerplate.

Why it became a project

Repeating the same logging, activity, and metric wiring across services made telemetry a strong candidate for one interface-driven, compile-time implementation.

Where it fits

Use it when

You want strongly typed OpenTelemetry-aligned telemetry from interfaces, with generated implementations and dependency-injection registration.

It may not fit when

Your telemetry is highly dynamic, cannot be described at compile time, or is already handled consistently by another instrumentation layer.

Use cases

Concrete examples of what Telemetry SourceGenerator does, and who each one is for.

Developer

Tracing, logging, and metrics from a single interface

You want OpenTelemetry activities, structured logs, and metrics around an order service, but you do not want to hand-write the ActivitySource, ILogger, and Meter wiring in every class.

csharp 
[ActivitySource]
[Logger]
[Meter]
public interface IOrderServiceTelemetry
{
    [Activity]
    [Info]
    [AutoCounter]
    Activity? PlacingOrder(int orderId, [Baggage] string region);
}

What you get: The generator emits the implementation and an AddOrderServiceTelemetry() DI extension; you register it once and inject the interface wherever telemetry is needed.

One interface replaces the ActivitySource, ILogger, and Meter boilerplate you would otherwise repeat in every service.

Read the guide →
Architect

Standardise telemetry names across services

You want consistent OpenTelemetry meter and activity-source names across many services instead of ad-hoc string literals scattered through the codebase.

csharp 
builder.AddServiceDefaults(
    TelemetryNames.MeterNames,
    TelemetryNames.ActivitySourceNames);

What you get: A generated TelemetryNames static class holds the names, so registration happens once at startup rather than in every service.

Naming conventions are generated, so snake_case tags and hierarchical metrics stay consistent without a review checklist.

Read the guide →

Packages

1 package

Purview.Telemetry.SourceGeneratorInstall ↓5.1.0—20,104

Install

.NET CLI
dotnet add package Purview.Telemetry.SourceGenerator