PPulse.Observability.AspNetCore 1.0.3

PPulse.Observability.AspNetCore

Policy Pulse observability integration for ASP.NET Core (.NET 8+) applications. Provides tracing, metrics, and structured logging export to the PPulse collector.

Installation

dotnet add package PPulse.Observability.AspNetCore

Setup

Call AddPolicyPulse on IServiceCollection in Program.cs:

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddPolicyPulse(
    configureOptions: opts =>
    {
        opts.AppCode = "MyApp";
        opts.AppName = "My Application";
        opts.Environment = "Production";
        opts.CollectorBaseUri = new Uri("https://your-collector/");
        opts.TenantCode = "your-tenant-code";
        opts.ApiKey = "your-api-key";
    },
    configureBuilder: b => b
        .WithMetrics().AddAspNetCoreMetrics()
        .WithTracing().AddAspNetCoreTracing()
        .WithLogging(builder.Logging)   // pass builder.Logging — applies log export immediately
);

Logging: WithLogging vs WithILoggingBuilder

In ASP.NET Core always use .WithLogging(builder.Logging), passing the WebApplicationBuilder.Logging instance. This applies the log export configuration eagerly when Build() is called internally by AddPolicyPulse.

Using .WithILoggingBuilder() alone inside AddPolicyPulse will silently skip log export — the binder delegate is created but never invoked, because AddPolicyPulse does not call LoggingBinder after building. .WithILoggingBuilder() is the right choice only for ASP.NET Framework (where you invoke LoggingBinder yourself) and Azure Functions (where the extension wires it up via ConfigureLogging).

Filtering exceptions

By default, all first-chance exceptions that occur during a faulted request (5xx) are evaluated. Use ConfigureException to control which exceptions are attached to the trace.

Namespace filtering

Restrict capture to exceptions whose stack trace passes through your own namespaces. Both include and exclude lists are supported and can be combined:

opts.ConfigureException = exOpts =>
{
    exOpts.IncludeNamespaces.Add("MyCompany.MyApp");
    exOpts.ExcludeNamespaces.Add("MyCompany.MyApp.Infrastructure.ThirdParty");
};

The stack walk stops at the first frame matching an included namespace. Frames in excluded namespaces are skipped. If IncludeNamespaces is empty, any frame not in ExcludeNamespaces qualifies.

Predicate filtering

For cases where namespace matching isn't expressive enough, supply a predicate. When a predicate is configured it is the sole decision maker — namespace rules are bypassed entirely:

opts.ConfigureException = exOpts =>
{
    exOpts.IncludeExceptionPredicate = ex =>
        ex is not OperationCanceledException && ex.StackTrace?.Contains("MyApp") == true;
};

Do not configure both a predicate and namespace lists — the predicate wins and the lists are ignored.

Note: Exception capture requires tracing to be configured. If .WithTracing().AddAspNetCoreTracing() is not called, Activity.Current will be null during requests and captured exceptions will be silently discarded with no enrichment of any span.

What is instrumented

• Inbound HTTP requests (via AddAspNetCoreTracing)
• Outbound HTTP calls
• SQL client operations
• Runtime and process metrics (via AddAspNetCoreMetrics)
• PPulse metadata headers (tenant, correlation, session) extracted from inbound requests and attached to traces and logs
• First-chance exceptions captured and attached to the active trace