Skip to main content
N
About

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.

5 criteria3 packages5-point checklist

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 and trade-offs

These options are starting points, not an exhaustive market list. Verify the current release, compatibility, license and advisory information for your project on the linked package pages.

1

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.
2

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.
3

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. 1Define 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. 2Configure 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. 3Validate 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.

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.

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 projectReview NuGet licenses before shippingAudit Central Package Management versions

Data, method and limits

Sources: the public NuGet v3 registry and NuBrowse editorial review. Refresh: package pages read current registry metadata when viewed; guide text is revised separately. Method: the shortlist favours distinct use cases and spells out trade-offs instead of calculating a quality score. Limit: validate the specific version, license, framework and operational requirements in your project.