Learn .NET - Observability & Production Support

#Introduction

In production, you cannot guess what is happening inside the application — you must see it. Episode 20 covers observability: the ability to understand a system's state from the outside through three pillars — logs, metrics, and traces.

You will strengthen logging with Serilog, integrate OpenTelemetry for tracing and metrics, install health checks, and prepare incident management and diagnostics procedures. Observability is not an add-on — it is your eyes in production.

#Logging with Serilog

#Structured Logging

Serilog writes logs as structured events with named properties — not just strings. Install and configure:

dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.Console

Then enable it in the host:

Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .Enrich.FromLogContext()
    .CreateLogger();
 
var builder = Host.CreateApplicationBuilder(args);
builder.Logging.ClearProviders();
builder.Logging.AddSerilog();

WriteTo.Console() sends logs to the console in a structured format, and Enrich.FromLogContext() adds context such as trace ids to every event. Serilog replaces plain console logging with output that can be parsed and aggregated.

#Sinks and Enrichment

Structured logs are sent to many sinks: console for development, Elasticsearch or Seq for aggregation, and files for archiving. A single log statement with structured properties enables queries like "all errors for user X in 10 minutes" — something impossible with free-form text logs.

#Metrics, Tracing, and OpenTelemetry

#OpenTelemetry as the Standard

OpenTelemetry unifies metrics, traces, and logs with a single cross-language SDK. In .NET:

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol

Enable automatic instrumentation for HTTP, database, and HttpClient:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddEntityFrameworkCoreInstrumentation())
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddMeter("Microsoft.AspNetCore.Hosting"));

WithTracing captures the path of every request from the API to the database, and WithMetrics records metrics such as request counts and durations. Everything is exported to backends like Prometheus, Grafana, or an OTLP collector.

#Traces as the Story of a Request

A trace consists of spans that tell the story of one request: the HTTP middleware, the database call, the call to another service. When a user reports slowness, the trace shows in which span the time was lost — no guessing.

#Health Checks and Monitoring Endpoints

#Installing Health Checks

Health checks tell the orchestrator and operations team that the application is healthy. Add an endpoint:

builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();
 
app.MapHealthChecks("/health");
app.MapHealthChecks("/health/ready");

AddDbContextCheck verifies the database connection — a real check, not just "the app is still alive". The /health/ready endpoint is used by Kubernetes as a readiness probe (episode 19), and /health/live for liveness.

#Alerts from Metrics

Metrics without alerts are just pretty graphs. Set alert rules on key metrics: rising error rate, p99 latency above target, or repeatedly failing health checks. A good alert says what is wrong and points to the relevant dashboard.

#Incident Management and Diagnostics

#The Incident Flow

When an incident happens, follow an agreed flow: detection (alert), severity classification, team communication, diagnosis, mitigation, then post-mortem. The main goal is reducing recovery time — MTTR — not just finding the root cause.

#Diagnostics Tools in Production

When you need to investigate a running process, the diagnostic tools from episode 15 work in production:

dotnet-dump collect --process-id 12345
dotnet-dump analyze dump.dmp

dotnet-dump collect records a snapshot of the process memory, and dotnet-dump analyze examines it interactively — looking for stalled threads, large objects, or deadlocks. Combining dumps with traces and logs gives a complete picture of an incident.

#Observability Practice Summary

• Use Serilog for structured logs with context.
• Integrate OpenTelemetry for traces and metrics.
• Install health checks that verify real dependencies.
• Apply alerts on key metrics, not just on errors.
• Prepare incident flows and diagnostics tools like dotnet-dump.

#Closing

Key takeaways:

• Observability consists of logs, metrics, and traces.
• Serilog writes structured events that are easy to query.
• OpenTelemetry unifies telemetry with a single SDK.
• Health checks give real health signals to the orchestrator.
• Alerts on key metrics speed up incident detection.
• dotnet-dump enables deep diagnosis in production.

In the next episode 21 we will discuss desktop and cross-platform apps — .NET MAUI for cross-platform mobile and desktop applications, WPF and WinForms for Windows, Blazor WebAssembly and Blazor Server, and packaging, distribution, and deployment of desktop and mobile applications.