Stop using String Interpolation when Logging in .NET

preview_player
Показать описание

Hello everybody I'm Nick and in this video I will explain why you should not be using string interpolated when logging in .NET. This applies to both the build in Microsoft.Extensions.Logging framework and also on the very popular Serilog one. Strucutred logging is extremely valuable and in this video we will see how string interpolated can remove that benefit.

Part of this video is sponsored by AWS

Timestamps
Intro - 0:00
The problem - 0:40
Visualizing logs - 7:55
A potential future solution - 13:11

Related videos

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet #logging
Рекомендации по теме
Комментарии
Автор

I have watched all of your videos on logging and I appreciate them a lot. But one thing I have not seen (and I've done some searching on this) is a good philosophy on WHAT to log and WHEN. Do i log every function/method invocation? What should I log as INFO as opposed to DEBUG? How do I word my log message templates? Is there a resource I can look at to get guidance on this?

UnnDunn
Автор

This is awesome! Thanks Nick. My work has been using string interpolation for logging for... probably a decade, I'm not sure, I haven't been here that long, but... There's a lot of code that uses string interpolation for logging and I think it would be difficult to go back and fix it all.. I'll have to bring this idea up if we ever move toward something like AWS Cloud Watch.

AJax
Автор

Woah 100k!! Congrats 🍾🎊 keep up the amazing work!

myuuiii
Автор

Thanks! One of my pet peeves in pull requests.

timagic
Автор

Good job Nick. We are doing this at my current job, and now I know why.

onlythestrongsurvive
Автор

Thanks! great video (and great channel), easy to understand. I never knew this and have now gone and changed all my logs in my current project. App insights now looks great!

Punkologist
Автор

How did I never heard of this before? Awesome video!

otaviomarchioli
Автор

This makes a lot of sense. I was not expecting that. I clicked on the video expecting to be annoyed by another unnecessary programing rule.

Автор

Great video Nick, Thanks. That's what I always recommend to my team members or anyone who is dealing with logs. BTW when it comes to logs, I prefer Azure it is a lot neater that AWS.

peymannaji
Автор

man im guilty of using string interpolation everywhere i can lol... i need to change.. thanks for quality content
keep coding ;)

aj.arunkumar
Автор

Hi Nick. Thanks for the awesome videos!
Could you maybe make a video about best practices on where to log, and where not to log.
For example, if you can only get ILogger via DI, should only those classes use it, or could it be passed in as a parameter to classes that do not use DI? And is it okay to use the Log.Logger static variable in Serilog, and when is it not?

DrHeinzDoofenshmirtz
Автор

The transcript of your intro is always good for an extra smile.
This time it is:
"Hello everybody I'm Nikki".
But I also had:
"Hello everybody I'm naked".

cdoubleplusgood
Автор

Excellent demonstration of industry best practices and congrats on 100K subs. Keep coding!

mouldtony
Автор

One other benefit is that if you have translations, templates can be translated because the placeholder stays the same, if you have strings that change because the values are part of them, it actually prevents you from translating them.

frossen
Автор

Thank you! Clear and concise and love your presenting personality :)

airforcepuddy
Автор

One edge case I still don´t have a good alternative to is when you want a specific property in a logging statement, but you don´t want it as part of the message template. Now, this would normally be solved by wrapping the LogContext with an Enricher or simply pushing a property onto the LogContext in a specific scope. But sometimes it feels like a lot of code pollution to add an entire enricher and/or a using-statement around a logging block. Alternatively you can still simply add the property in the logging statement, but Rider will of course remind you that you aren't using the property in the message-template which leaves the code vulnerable to being changed if you happen to run an auto-clean operation.

buriedstpatrick
Автор

I've been explaining not to do this as that breaks structured logging and a lot of devs don't care. Problem is simply most devs never actually need to diagnose production issues with logs.

RamonSmits
Автор

Congrats for 100k subscriber .

Another great video.

wellingtonmartinsalves
Автор

Really good video on this topic! Finally a good explanation :D

Dustyy
Автор

it doesn't matter what you log, just worry about when you render the content. Render it in <pre></pre> !!!!

richardclarke