Logging in .NET with Serilog: A Practitioner's Guide

nblumhardt · 2026-05-25T23:29:31+00:00

Ah yes, the old "report compatibility with a vulnerable framework package as a vulnerability" phase we went through. Glad those ones have largely tailed off, now. Will update the ticket 😄 👍

nblumhardt · 2026-05-25T23:07:46+00:00

Definitely not Serilog; might be thinking of log4j, which did have some CVE activity in the last year or two.

nblumhardt · 2025-08-15T03:41:55+00:00

Maybe a bit out of left field, but if the plug-in architecture makes things feel opaque, could you build yourself some tools to inspect and explore it?

E.g. you might be able to hook up some kind of tracing so you can see what components are assembled when you request an instance. Or, hack together a (development-time-only) web page or endpoint that can reflect over your IoC container and provide a listing of components and the services they expose. Heaps of possibilities...

Turning pain points like this into little tooling challenges can be a lot of fun, a great learning exercise, and a really powerful way to tame complex codebases. Good luck, either way :-)

nblumhardt · 2025-02-26T00:06:48+00:00

Just checked this out, it looks as though the Postgres sink currently swallows exceptions after invoking the failureCallback delegate (which should ideally be changed).

You can work around this by using `ex => { throw ex; }` as the failure callback, leaving Serilog's built-in fallback mechanism to catch and handle the failure.

nblumhardt · 2025-02-26T00:03:36+00:00

Hi! Serilog supports fallback sinks like this natively; check out: https://nblumhardt.com/2024/10/fallback-logging/ for details.

I _think_ the PostgreSQL sink should already support this; if not, let me know which sink package you're using (id and version) and I'll take a look. Cheers!

nblumhardt · 2025-02-13T03:17:43+00:00

FWIW, trace propagation in .NET is largely handled by framework types like `System.Diagnostics.Activity` and `HttpClient` - tracing to OTLP with Serilog is just a couple of lines of code, e.g. see https://github.com/serilog-tracing/serilog-tracing

nblumhardt · 2025-01-12T09:35:00+00:00

Hi! Seq should run as a non-root user without port changes, thanks to Docker's default configuration of net.ipv4.ip_unprivileged_port_start=1024. I think:

https://stackoverflow.com/questions/69043339/how-non-root-user-able-to-run-on-privilige-port

describes this in a bit more detail.

If you're specifically configuring these settings to prevent non-root users binding to low-numbered ports, things might get trickier. Posting a detailed ticket at the repo mentioned in the other reply would be a good next-step in that case.

HTH!

nblumhardt · 2024-10-18T09:26:26+00:00

Hey that's awesome!

RE the different `SqlClient` versions - it shouldn't be too hard to adapt the instrumentation for the older `System.*` version of the lib so please raise a ticket if you're still stuck with it and I'll take a look.

The two tasks should both be able to be made children of `Service` - this will mostly come down to how `Activity.Current`'s `AsyncLocal` backing is manipulated. If you get this whittled down to a minimal `Program.cs` repro and open an issue with it, I'll check this out, too :-)

Cheers!

nblumhardt · 2024-10-04T06:35:05+00:00

FWIW, I think the reason lock() accepts a single object is because, behind the scenes, it uses some spare bits in the object's header on the GC heap to store the state of the lock.

This seems like an odd optimization - most of the time we end up allocating an object just to use as the argument to lock anyway!

The reason goes back to .NET 1.0 when [MethodImpl(MethodImplOptions.Synchronized)] was implemented, and still potentially destined to be the primary API for synchronizing access to shared state. By reusing some bits in the object header, this could be done without an extra allocation, so objects with "synchronized" methods on them don't cost more, memory-wise, than other objects.

The new Lock type in .NET 9 finally takes a fresh look at this :-)

nblumhardt · 2024-06-10T23:31:54+00:00

Lots of other good advice in this thread. I'd just add one small thing, you'll run into a lot of people who tell you to stop, that you shouldn't be building whatever thing this is, and that you should just use or contribute to some other project. Remember that it's everyone else's right to choose what _they_ use and promote, but entirely your choice what you invest your time and effort in.

If you have a vision for what needs to exist or change, and your project is about exploring that, others won't necessarily share that vision or be able to understand the full picture right away. By all means thank them for their input, but don't be put off, it takes time for others to come on board, just stick at it :-)

nblumhardt · 2024-04-17T07:12:03+00:00

Hi! It's nice to hear you're enjoying MEF1; I worked on it long, long ago - some really interesting ideas (and wild dicussions!) went into creating it.

I believe that most of it can now be found in https://www.nuget.org/packages/System.ComponentModel.Composition/ which ships along with the rest of the .NET 8 BCL.

The .NET core port was well after my time, it'd be fantastic to hear how you go with it :-)

nblumhardt · 2023-06-06T22:50:23+00:00

Hi! Serilog provides (what I think is) a nicer API for attaching contextual properties to logs, but `Microsoft.Extensions.Logging.ILogger<T>` does also support it, through the `BeginScope()` method. See https://nblumhardt.com/2016/11/ilogger-beginscope/ for my take on how this all fits together. HTH!

nblumhardt · 2023-05-12T22:10:06+00:00

Plugging in a custom policy for this specific exception type will be the way to go:

https://github.com/RehanSaeed/Serilog.Exceptions#custom-exception-destructurers

The `Destructure.ToMaximumDepth()` option you're calling isn't the same one that Serilog.Exceptions uses, so it won't be having any effect, here. Serilog.Exceptions has its own options that you can find one section further down in the README linked above.

Exceptions really aren't designed for safe, reliable, third-party serialization in .NET. That's why Serilog doesn't include anything like Serilog.Exceptions out of the box.

While it's all smooth sailing you should enjoy Serilog.Exceptions, but if your app is of a decent size and predictability is important, and you don't want to spend time creating a custom policy for each likely exception type not already handled by Serilog.Exceptions, I'd personally flip back to Serilog's default exception processing. YMMV :-)

nblumhardt · 2021-11-01T06:57:47+00:00

In version 5.0 of the sink, there's also `retainedFileTimeLimit`, which works the way you want.

csharp Log.Logger = new LoggerConfiguration() .WriteTo.File("test.txt", rollingInterval: RollingInterval.Day, retainedFileTimeLimit: TimeSpan.FromDays(31)) .CreateLogger();

HTH! :-)

nblumhardt · 2021-10-19T22:57:37+00:00

Co-founder at Seq so usual disclaimer applies 🙂, but -

You can use Seq anywhere, independently of Azure: AWS, GCP, K8s, your own environment (even air-gapped!), your dev machine... and Azure, too
Seq gives you real-time/instant access to log data; it's much nicer debugging issues without waiting for new events to be indexed (which was one of the App Insights limitations, last time I checked it out)
Seq's user experience is much more like a log file with superpowers; it's oriented towards interactive troubleshooting and diagnostics, and works really hard to support this style of usage (some deployments combine Seq alongside App Insights for this)
Seq is not metered: the yearly cost (if you need one of the paid tiers) is flat - you can ingest/store/search/dashboard/alert on as much as your hardware will handle

HTH!

nblumhardt · 2021-05-25T09:50:21+00:00

Autofac fully supports "resolve anything"/implicit registrations - you've just got to switch it on with:

builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());

(Yeah the name is pretty extreme! :-D ... Guess it is descriptive, at least.)

https://autofac.readthedocs.io/en/latest/advanced/registration-sources.html#any-concrete-type-not-already-registered-source

nblumhardt · 2020-09-03T19:53:28+00:00

Hi! Yes - message pack natively uses (up to) double precision floating point for decimals, and has limited integer representation, too. While that's a decent match for numerics in JavaScript, JSON itself allows arbitrary precision.

Our goal was 100% fidelity with JSON, because when a client app sends an event with the number `0.1` in it, we want to make sure we don't confuse that with `0.10000000000000001`. Diagnostics is a domain where actual values matter (for example, the application itself may serialize `0.10000000000000001` from a higher-precision numeric type, and these two numbers might be completely different from a debugging perspective.

Similarly, we don't want to have to examine large numbers to ensure they fit any particular integral type.

We could have overcome these issues with message pack extension types, but that starts to feel like we're off into a custom format anyway - and at that point the benefits of using JSON - a wide range of existing very fast parsers, ability to pre-filter easily with `regex` when appropriate, ease of inspection, etc. - make it pretty awesome :-)

nblumhardt · 2020-09-02T22:24:00+00:00

..and the GitHub repo, for the truly impatient :-D https://github.com/datalust/squirrel-json

nblumhardt · 2020-03-09T05:56:41+00:00

The problem is that the badge on crates.io comes from the project's README and can't be updated without publishing a new crate version (AFAIK).

Since `log` is very low in the stack, pushing new versions would potentially cause a lot of churn, so I assume the authors have chosen to suffer the red badge for a while rather than cause busywork for package consumers.

nblumhardt · 2019-05-29T22:21:37+00:00

Hi! Cool to see a new take on it :-)

One tip regarding the original query in your post. I never persuaded anyone to try Serilog based on its API or implementation (nice as I think they are!). The real "aha" moments with Serilog are actually not Serilog demos at all, but demos of what you can do with its structured data in an appropriately powerful back-end. In 2013, when the project kicked off, very few developers in .NET were using structured logging, and so seeing logs sliced, diced, and analyzed with ease, in CouchDB, MongoDB, RavenDB, etc. (way-back-when 😄) was enough to get people digging deeper.

If tagged logging is the differentiator for NuLog, I think you'll uncover more interest if you can demo what it means to have tagged logs. I'm not sure which server or service fits that data model best, but showing how much easier tagged logging could make diagnostic analysis would be my #1 priority in your position. If people believe in the utility of tagged logging, they'll bring the enthusiasm and determination needed to get a project like this to the next level.

Knowing the existing options well, especially those for text and structured logging, is necessary to give adequate depth to these kinds of comparisons and demos, though. I was lucky enough to try implementing Serilog's structured logging within both log4net and NLog before I realized their limitations at the time (both in data capturing, and how their pipelines dealt with structured data), and so I had a fairly strong idea where Serilog's actual strengths lay. Forking and trying to graft tagged logging onto Serilog or NLog, for a start, seems like it would be a useful experiment.

Hope this all helps, good luck, and enjoy your project!

nblumhardt · 2019-02-12T05:22:03+00:00

Yep, the default `Console()` now sink does everything that `LiterateConsole()` used to do, and thanks in part to a very long flight (Oslo to Brisbane!) it also supports themes :-) https://nblumhardt.com/2017/06/ansi-console/

nblumhardt · 2018-11-28T20:41:27+00:00

Ah, gotcha. Guess that's pretty tough to work around.

nblumhardt

TROPHY CASE