Most .NET teams start logging the same way: they inject ILogger<T>, call _logger.LogInformation(...), and move on. Then the application grows. Incidents happen at 2 AM. Someone needs to find one specific transaction in a sea of plain-text log lines, and the team discovers that not all logging strategies age the same way.
The provider you pick matters less than the structure you log with. The full setup - Serilog with enrichers, request logging, and sinks - is on Patreon. Chapter 14 of the ASP.NET Core Web API: Zero to Production course wires structured logging and OpenTelemetry into one running API.
Structured logging is no longer a nice-to-have. In enterprise .NET environments where logs feed into centralized observability platforms - Elastic, Seq, Datadog, Azure Monitor - the shape of your log data at inception determines how useful it is at diagnosis time. This guide helps engineering leads and senior architects make the right standardization choice between the three dominant options: Microsoft.Extensions.Logging (MEL/ILogger), Serilog, and NLog.
What Structured Logging Actually Solves
Before comparing frameworks, it helps to be precise about the problem. Traditional string interpolation produces flat, unindexed log lines. A log entry like "Order 12345 placed by user 98 for $450" is readable to a human but opaque to a log aggregator trying to build a dashboard of order value over time.
Structured logging treats log events as data. Each log entry carries a template and a set of named properties that the log pipeline stores as searchable, indexable fields. The same event becomes OrderId=12345, UserId=98, Amount=450 - independently filterable, alertable, and aggregatable.
The framework you choose controls how easily your team produces, enriches, and routes these structured events.
The Three Contenders
Microsoft.Extensions.Logging (MEL / ILogger)
MEL is the built-in abstraction layer that ships with ASP.NET Core. It defines the ILogger<T> interface your application code depends on. Crucially, it is an abstraction only - the actual log destination is determined by which provider you register.
Out of the box, the default providers (Console, Debug, EventSource) support message templates via the {PropertyName} syntax. However, the built-in providers have significant limitations in production enterprise scenarios: minimal sink ecosystem, no enrichment pipeline, and limited support for structured output formats that log aggregators expect.
Where MEL alone works: Microservices with simple console output piped to a log aggregator (Kubernetes stdout → Fluent Bit → Elastic). Teams that want zero external dependencies.
Where it falls short: Complex enrichment needs, multi-sink routing, audit logging, or when the team needs Seq/Splunk sinks without writing custom providers.
Serilog
Serilog is a third-party logging library built ground-up for structured logging. It integrates with MEL as a provider (via UseSerilog()), so your application code still uses ILogger<T> - you just replace the underlying engine.
Serilog's strength is its ecosystem. It has over 150 community sinks covering virtually every log destination: Seq, Elastic, Datadog, Splunk, Azure Application Insights, SQL Server, and more. Its enricher model lets you attach contextual properties to every log event without modifying call sites - machine name, environment, correlation ID, tenant ID, request path.
The DestructureUsing API gives fine-grained control over how complex objects are serialized, which matters in financial and healthcare applications where certain fields must be masked or excluded from logs entirely.
Where Serilog wins: Teams that need a rich sink ecosystem, deep enrichment, PII scrubbing, or integration with Seq for structured querying. Strong community, actively maintained, first-class support in popular libraries (Seq, OpenTelemetry, Elastic APM).
Where it adds friction: Configuration via code or JSON is more verbose. In organizations with strict binary-vetting policies, adding an external dependency requires approval overhead.
NLog
NLog is the oldest of the three and has a longer track record in traditional .NET Framework applications. Like Serilog, it integrates with MEL as a provider. NLog uses XML or JSON configuration files by convention, which some enterprise security teams prefer because logging behavior can be changed without redeployment.
NLog's target model is functionally equivalent to Serilog's sinks: Console, File, Database, Splunk, Elastic, and many more. Its layout renderer system allows injecting context - similar to Serilog enrichers - via \({aspnet-request-ip}, \){aspnet-mvc-action}, and other pre-built renderers.
Where NLog wins: Teams migrating from .NET Framework where NLog was already the standard. Organizations that require externalized, redeployment-free logging configuration. XML-based configuration is more auditable in some regulated environments.
Where it adds friction: Community momentum has shifted toward Serilog in the cloud-native space. Fewer sink libraries, and structured output for some destinations requires more manual configuration.
The Decision Framework
Standardizing Across Multiple Teams
In multi-team enterprise environments, the logging framework becomes part of your internal platform. The choice should favor the option that is easiest to wrap in an opinionated internal NuGet package. Both Serilog and NLog integrate cleanly with MEL, so application code stays framework-agnostic regardless of the choice. The internal platform team owns the bootstrap configuration; application teams own log levels and categories.
Serilog's fluent API is generally easier to wrap into a consistent internal library with sensible defaults. NLog's XML configuration is easier to manage centrally via a shared config file or template.
If your organization already uses a specific observability stack, let that drive the decision. Seq is built by the Serilog team and integrates most naturally with it. Elastic and Datadog have first-class Serilog sinks that are actively maintained. NLog has equivalents but they receive less community investment.
For OpenTelemetry-centric observability strategies (the emerging enterprise standard), both Serilog and NLog integrate via the MEL bridge. Logs, traces, and metrics flow through the same pipeline regardless of which logging library sits behind ILogger<T>.
Regulated and Audited Environments
Financial services, healthcare, and government environments introduce constraints that shift the calculus. The key questions are: Can PII appear in logs? Must logs be immutable? Must log configuration be externalized and auditable?
Serilog's destructuring policies and output templates make PII exclusion deterministic and testable. NLog's externalized XML configuration makes audit trails for log policy changes easier. Neither is definitively superior here - the right answer depends on your specific compliance requirements.
Team Familiarity and Migration Cost
In greenfield projects, Serilog is the modern default. In organizations with significant .NET Framework legacy, NLog is often already present and migrating requires justification. The migration cost of switching from NLog to Serilog mid-project is non-trivial; do it at a boundary (new service, new version, platform upgrade) rather than as a refactor in flight.
Using MEL with the built-in providers as a temporary standard is defensible if your team is still choosing a platform and you want to defer the decision - but treat it as temporary. Production systems without a structured logging provider will accumulate technical debt the moment you need to query logs at scale.
Enrichment: The Hidden Differentiator
Enrichment is where enterprise logging strategy separates from tutorial-level logging. Every log event in a production application should carry: environment name, service name, version, machine/pod name, request correlation ID, user/tenant ID (where applicable), and operation context.
Without enrichment, finding all logs related to a single request across multiple services is a manual grep exercise. With enrichment, it is a single indexed query.
Both Serilog and NLog support enrichment. Serilog's enricher interface is simpler to implement and has a larger library of ready-made enrichers (including ASP.NET Core request properties, ambient context from LogContext, and OpenTelemetry trace correlation). NLog's layout renderers cover similar ground but require more configuration to achieve the same ambient enrichment behavior.
MEL alone, with the built-in providers, does not have a composable enrichment mechanism. This is the single most important reason MEL-only is insufficient for enterprise production systems.
Log Level Governance
Regardless of which framework you choose, log level governance is an operational discipline problem, not a library problem. Enterprise teams should define and enforce log level conventions:
Verbose/Trace: Reserved for local development, never enabled in production
Debug: Integration points, useful for staging investigations
Information: Normal operational events with business significance
Warning: Degraded but recoverable state, requires monitoring attention
Error: Request or operation failed, requires alert
Fatal/Critical: Service-level failures requiring immediate intervention
The framework does not enforce these conventions - your engineering standards and PR review process do. Both Serilog and NLog support dynamic log level changes (hot reload via configuration) which is essential in production when you need to temporarily elevate a service to Debug without redeployment.
Making the Call
For most enterprise teams starting or standardizing today, Serilog is the right choice. The ecosystem advantage, enrichment model, PII handling, and community momentum are decisive. Wrap it in an internal library so application teams never configure it directly, and the friction disappears.
Choose NLog if you are operating in a hybrid .NET Framework/.NET 8+ environment where NLog is already the standard, or if your organization requires externalized XML-based log configuration as a governance requirement.
Stay with MEL providers only if you are intentionally building a zero-external-dependency policy and your observability platform ingests raw console JSON via a sidecar - which is viable in pure Kubernetes environments with a mature platform team.
Whatever you choose, the decision that matters most is making it explicit, writing it into your architectural decision records, and enforcing it as a team standard. Inconsistency across services - some using Serilog, some NLog, some raw MEL - is the outcome that costs the most at 2 AM when you are hunting a production incident across fragmented log formats.
Frequently Asked Questions
Can I use Serilog and still depend only on ILogger in my application code? Yes, and you should. Serilog (and NLog) register as MEL providers via UseSerilog() or UseNLog() in your host configuration. Application code injects ILogger<T> as normal. The logging library is an infrastructure concern, kept out of your domain and application layers. This also makes testing straightforward - you mock ILogger<T>, not Serilog.
Does switching from NLog to Serilog require changing application code? In a properly layered application where all logging happens through ILogger<T>, switching the underlying provider is a host-level configuration change. Application code requires no modification. The caveat is custom NLog targets or layout renderers that may have been written directly - those would need to be rewritten as Serilog sinks or enrichers.
Is structured logging a performance concern in high-throughput APIs? Both Serilog and NLog are designed for high-throughput use. Asynchronous sink configurations (using buffered or batched writes) keep the logging path off the critical request path. The performance cost of structured logging versus string interpolation is negligible when log levels are set appropriately and expensive evaluation is guarded. The bigger risk is unguarded verbose/debug logging enabled accidentally in production, which is a configuration and governance problem.
How does structured logging relate to OpenTelemetry? OpenTelemetry defines the Logs signal as part of its three-pillar model (Logs, Metrics, Traces). ASP.NET Core's MEL abstraction bridges directly to the OpenTelemetry SDK via OpenTelemetry.Extensions.Logging. Both Serilog and NLog emit through MEL when used as providers, so they participate in the OpenTelemetry pipeline automatically. Serilog also has a native OpenTelemetry sink (Serilog.Sinks.OpenTelemetry) for teams that want to route logs directly through OTLP without going through the MEL bridge.
Should each microservice choose its own logging library, or should the platform enforce one? Enforce one at the platform level. Heterogeneous logging libraries across a microservices estate produce inconsistent log schemas, inconsistent enrichment, and higher operational overhead. The internal platform team should provide a blessed, pre-configured logging bootstrap package that all services adopt. Individual teams choose their log levels and categories - they should not choose the framework.
What is the right approach for logging in shared class libraries? Shared libraries and NuGet packages should always depend only on Microsoft.Extensions.Logging.Abstractions. Never take a hard dependency on Serilog or NLog in a library. This lets consuming applications - which may use any logging provider - receive log events from your library without a framework mismatch. The application host wires the provider; the library stays agnostic.
How do we handle PII in logs across an enterprise? PII in logs is a data governance and compliance risk. Serilog's destructuring policies allow you to exclude or mask specific properties before they reach any sink - implemented once in the platform bootstrap, enforced everywhere. NLog achieves similar results through layout masking and custom targets. Neither framework eliminates the human discipline of not logging sensitive data in the first place, but both provide mechanisms to catch and neutralize accidental exposure at the pipeline level. Document your PII policy in your architectural decision records and validate it with integration tests that assert certain fields are absent from log output.
About the Author
Celin Daniel is Co-founder of Coding Droplets with 13+ years of hands-on experience building, shipping, and operating .NET and ASP.NET Core systems in production. The guidance here comes from real projects and production incidents, not theory.
