Innovabit.DotNet.Interceptors.Telemetry 2.0.117

Innovabit.DotNet.Interceptors.Telemetry

Distributed tracing and metrics for Innovabit.DotNet.Interceptors via [Traced] and [Measured]. There is no provider package to pick: the interceptors publish through .NET's own ActivitySource and Meter, which OpenTelemetry — or any other collector built on System.Diagnostics — consumes directly.

Usage

services
    .AddInterceptors()
    .AddTelemetry();                  // or .AddTracing() / .AddMetrics() separately

services.AddScopedWithInterception<IPaymentService, PaymentService>();

Point your collector at the source and meter — they are only named constants, so there is nothing to keep in sync by hand:

services.AddOpenTelemetry()
    .WithTracing(t => t.AddSource(TelemetryDefaults.ActivitySourceName))
    .WithMetrics(m => m.AddMeter(TelemetryDefaults.MeterName));

public class PaymentService : IPaymentService
{
    [Traced(Kind = ActivityKind.Client)]
    [Measured]
    public Task<Receipt> ChargeAsync(Order order, CancellationToken cancellationToken) { ... }
}

[Traced]

Wraps the method in a span: started before the call, ended when it returns, marked as failed with an exception event when it throws. Spans nest through Activity.Current, so traced methods calling each other produce a tree without any extra plumbing.

Tags follow OpenTelemetry's semantic conventions (code.function, code.namespace), and a failure sets an Error status plus the standard exception event with exception.type, exception.message and exception.stacktrace.

Arguments are off by default

Arguments routinely carry personal data and traces usually leave the building, so RecordArguments is opt-in. Even then, CancellationToken parameters are skipped and parameters marked [TelemetryIgnore] are recorded as *** — visibly withheld rather than silently missing:

[Traced(RecordArguments = true)]
public Task<Receipt> ChargeAsync(string orderId, [TelemetryIgnore] string cardNumber) { ... }

[TelemetryIgnore] keeps a parameter out of spans specifically. The cross-cutting [Sensitive] and [Mask] from the core package keep it out of every record the suite writes — logs, audit entries and exception notifications included — and are applied to span tags too, including a [return: Sensitive] return value.

Cost when nobody is listening

ActivitySource.StartActivity returns null when no collector subscribed to the source, and the interceptor then simply proceeds. An application that ships with the attributes but without tracing enabled pays for one dictionary lookup and one null check per call.

[Measured]

Records three instruments, shared by every measured method and told apart by tags — so adding the attribute to another method does not add another metric to your cardinality budget:

Every measurement is tagged with operation, code.function, code.namespace and status (ok/error), plus exception.type when the call threw. A failed call increments both calls and errors, so the error rate is simply errors / calls.

Ordering

Telemetry runs outermost, at negative orders on the InterceptorOrders scale:

Tracing -200 → Metrics -100 → Logging 0 → Validation 100 → … → Transaction 700

That is deliberate. The span and the recorded duration cover everything the rest of the pipeline does — the retries, the wait before each attempt, the cache lookup, the transaction — which is what the caller actually experienced. Put them anywhere else and a method that took four seconds across three retries reports as the 1.3 seconds of its last attempt.

Renaming the source and meter

services.AddInterceptors()
    .ConfigureTelemetry(o =>
    {
        o.ActivitySourceName = "Contoso.Ordering";
        o.MeterName = "Contoso.Ordering";
    })
    .AddTelemetry();

Remember to subscribe your collector to the new names instead of the defaults.

License

MIT