You are doing logging in .NET wrong. Let’s fix it. - Nick Chapsas - NDC Oslo 2023

Logging is a vital part of every application that runs in production. It is in place to tell a story about the lifecycle of its runtime and make it easy for developers to debug a system and identify what failed and how when things go wrong. It is, however, extremely easy to get it wrong, and the problems caused can stay hidden for years. In this session, I will talk you through all the possible issues that logging can cause and show you how you can fix every single one of them.

More of Nick Chapsas here:
@nickchapsas

Check out our new channel:
NDC Clips:
@ndcclips

Check out more of our featured speakers and talks at

[nickchapsas]

To those complaining about the drinking: I had a throat inflammation and I had to keep drinking water so I could talk. Do you think I had 100 sardines and then decided to give a talk?

[DarrinCullop]

@nickchapsas, great talk, but want to clarify one point for you from 31:00 :
"None" has to be at the end of the enumeration because it isn't actually used to log messages. It's used as a value for a provider's minimum level to effectively disable it.

Having it at the end optimizes the IsEnabled check so that there is only one single comparison to make to determine both if the provider is enabled and if the message should be logged. That only works if None is higher than the highest value used by actual messages.

It was absolutely done on purpose and not because "they forgot" and had to tack it on at the end.

[abbasalabbas]

Nick, I like the way you describe and implement ideas. I started to watch your videos from 2019 and you really gave me so much information. You are one of the creators I'm really interested in any video you publish... thanks alot...

[being_aslam_tiger]

Thanks, Nick, for making this video possible. ❤

[frddyfrsh]

Nick, which I value a lot, misses a few important things.
1. When you have structured logs, you can filter for you preferred level >= warning
2. to fix complex bugs, you usually need all log levels, not only the warning „something went wrong“. And to raise the log level afterwards is often to late, because the problem already happenp but you have too less info to fix it, because you only logged >= warning.
3. structured logs can be condensed, for example: older than one day: delete everything below warning
With this you get the best of both worlds.

[UmarWaqas-vl]

Thanks Nick
Listening you is also amazing along with learning.
Enjoyed your session and learnt meaningful

[fullstackdotnet]

Logging Rules by Nixk
1. Message is actually the message template and should be treated as such, dont use string interpolation or concetatnation or formatting
2. Use structured logging and use good parameter names for better search and debugging experience
3. Prevent boxing for inactive log levels, avoid passing objects use value types where possible
4. Consider using source generated loggers ( Maybe? you probably won't need it )
5. Use log levels appropriately, do not over log, logs are just one tool, use other tools to monitor your systems health.
6. Use Warning as the default log level
7. Log what is necessary to tell a good story, Logs dont need to be verbose, they can be short and consice and yet provide enough information to debug and understand system behavior

[ishitvyas]

Thanks to what you called clickbait got my attention while learning .Net concepts on YouTube a few months back. From that date till today, I've never stopped learning and have taught me what I couldn't learn in 5 years of my career. Keep those videos coming. You're doing god's work! Thanks a lot man!

[lldadb]

Great talk! I think staying hydrated was a major part of why it was great. 🙃

[doom-child]

You keep saying that it's not a performance talk, but so much of what you talk about is ONLY important when performance is in question. Boxing, for example, has absolutely nothing to do with how logs are collected, stored, or queried. It's ONLY a concern if I'm trying to optimize memory usage in my application.

This feels way more like a talk that should have been titled "Your logging is too slow (sometimes)".

[Kevin-ldpp]

Hey! Nice talk, thank you very much :)

[rlyonsiii]

Hi Nick,
At the 35:55 mark in your slide at the bottom should read logger.LogPaymentFailed(id, status) you have Error in the method name not matching the slide. 👍

[thefattysplace]

Removing performance from the equation, I generally only log what will actually be looked at (which in some cases can be nothing), and use structured logging so you can investigate it easier later. Doing anything else is a waste. This doesn't mean that some scenarios won't require full logging, but only if it's going to be looked at and is useful later on (i.e full traceability on financial apps may be warranted).

[codingwithtien]

It's an interesting, fun, and useful presentation. Well done Nick.

[spottedmahn]

42:07 if we default to warning ⚠️, when that happens, we will probably need info ℹ️ or lower to understand what is wrong 🤔

Great content, thanks!!

[nighswimming]

Rule 7 is bollocks, oftentimes the only way to find out what went wrong is to trace earlier info log messages.

[stefanotorelli]

...and did you ever had a client that wants "translated" log messages based on the user session locale?

[emerelle]

Interesting Video. I did not understand very much. Being just a Newbie writing some (Windows) PowerShell Scripts doing very basic file operations. I recently discovered "log4net" and do stuff like $Log.Information(("Delete File {0}" -f $PSItem.FullName)) or $Log.Error((Out-String -InputObject $Error[0])) but maybe I will one day come back to this video if I understand more. :P

[andriisnihyr]

Nick, thanks for the talk. Would be cool to see a follow-up video on having proper metrics and tracing to troubleshoot complex situations. For now my team has to rely on info logs to tell the full story.

[CottidaeSEA]

There's a guy at work who adds the most useless logs ever known to man. They provide enough information to know the logging was executed. No more, no less.