Decision Guide

Logging packages for .NET

Start with the logging abstraction already used by the host. The practical decision is usually about provider pipeline, event shape, correlation, and operations model rather than whether an application should log at all.

5decision criteria

3packages compared

5pre-launch checks

The decision Shortlist Implementation plan Pitfalls & checklist When to revisit

The decision to make

Which logging provider fits an ASP.NET Core or worker application?

Whether the application already uses Microsoft.Extensions.Logging abstractions.
Required structured fields, enrichment, filtering, correlation IDs and trace context propagation.
The destinations you operate: console, files, OpenTelemetry collectors, log servers or cloud services.
Operational needs such as JSON output, retention, sampling, PII redaction and failure handling.
Whether request logging, background-job logging and distributed tracing should share one event model.

Shortlist & Trade-offs

Curated starting points to compare. Always evaluate suitability against your specific project requirements.

Microsoft.Extensions.Logging

The standard logging abstraction and default implementation used throughout modern .NET hosting.

Inspect package

Best fit: Applications that want provider-agnostic logging and straightforward integration with .NET hosts.

Validate first: Advanced routing and event shaping are supplied by providers or additional configuration, not the abstraction alone.

Serilog.AspNetCore

Serilog integration for ASP.NET Core, centred on structured events and a large sink ecosystem.

Inspect package

Best fit: Teams that need rich structured event properties and deliberate control over log destinations.

Validate first: The desired sinks and configuration need to be selected and operated explicitly.

NLog.Web.AspNetCore

NLog integration for ASP.NET Core with flexible target and rule configuration.

Inspect package

Best fit: Teams already using NLog or requiring its configuration-oriented routing model.

Validate first: Avoid adding a second logging pipeline when the existing provider already meets the requirement.

Practical implementation plan

1
Define a small event vocabulary first: stable event IDs or names, log levels, required correlation fields, and data classification rules. Keep messages useful without placing secrets or raw personal data in properties.
2
Configure a single provider pipeline through Microsoft.Extensions.Logging. Add request logging, trace correlation, and scoped properties at host boundaries rather than manually in every method.
3
Validate operations end-to-end: query a failed request by correlation ID, verify retention and access controls, and load-test the chosen sink's back-pressure behavior.

Risk

Common pitfalls

Logging passwords, access tokens, authorization headers, or unbounded request bodies because structured fields feel harmless.
Using interpolated strings for high-volume logs instead of message templates, which loses structured properties and performs unnecessary work when disabled.
Treating every exception as an error at every layer, creating duplicate events without adding diagnostic context.

Checklist

Before production

Production log levels and category overrides are reviewed for signal-to-noise ratio.
Sensitive-data redaction, retention, encryption, and access policies are verified.
Logs carry request, trace, tenant, and job correlation where relevant.
Sink failures cannot block or crash the main request path unexpectedly.
A runbook links important event IDs to actionable remediation steps.

When to revisit this choice

Review logging choices when observability moves to OpenTelemetry, when retention or compliance requirements change, or when new sensitive-data redaction rules are introduced.

Put this decision into practice

Audit NuGet dependencies in a .NET project Review NuGet licenses before shipping Audit Central Package Management versions