LoggerHelper is a Serilog orchestrator, not a replacement: it routes log levels to sinks from JSON and keeps ILogger<T> in your code. This page says what that buys you and what it costs.
| LoggerHelper v5 | Serilog (plain) | NLog | |
|---|---|---|---|
| Per-level sink routing via JSON | Native (Routes[].Levels) | Sub-loggers / expressions in code | FilteringTargetWrapper / rules |
ILogger<T> without code changes | Yes | Via bridge | Yes |
| Modular sinks as NuGet packages | Yes (10 sinks, auto-discovered) | Yes (manual configuration) | Yes |
| Sink health / error diagnostics | Built in (ILoadedSinkStore, ILogErrorStore) | Self-log only | Internal log only |
| Embedded dashboard | Optional package | — | — |
| MCP server for AI assistants | Optional package | — | — |
| OpenTelemetry trace correlation | Yes | Partial | Via extension |
| Maturity and ecosystem | Young, small | Standard, huge | Established |
BenchmarkDotNet, .NET 9, no-op sink (framework overhead only, no I/O). Single message:
| Library | Mean | Allocated |
|---|---|---|
| NLog | ~94 ns | 176 B |
| Serilog | ~182 ns | 384 B |
| LoggerHelper | ~592 ns | 1152 B |
LoggerHelper costs roughly 3× plain Serilog per message. For a typical web API this is negligible next to the I/O of the sink itself. For a hot path logging millions of events per second, use Serilog directly. Full tables: benchmarks.md.
Pick LoggerHelper when you want to change which sink gets which level by editing JSON, install sinks as packages, and see sink health without extra infrastructure.
Pick plain Serilog when you need maximum throughput, a mature ecosystem, or full programmatic control of the pipeline. LoggerHelper sits on top of it, so you can migrate later.
Pick NLog if you already have NLog rules and targets that work, or you prefer its XML configuration model.
Calling third-party APIs? See the HttpHelper comparison with Refit and Flurl.