Skip to content
This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/content/posts/2024-07-24-logging-messages.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Admittedly, I didn't know as much about logging as I should have 🤷🏻‍♂

ASP.NET Core makes it easy to connect to a variety of logging providers. You can find out more about setting up logging [here](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-8.0). I want to focus on the messages you pass to the logger.

The messages get passed using a message template. This allows for structured logging. I read that was important because logging providers can store the parameters in the message template as fields. What does that look like and why is that important? Sometimes I need to see it in action to cement my understanding.
The messages get passed using a message template. This allows for [semantic or structured logging](https://github.com/NLog/NLog/wiki/How-to-use-structured-logging). I read that was important because logging providers can store the parameters in the message template as fields. What does that look like and why is that important? Sometimes I need to see it in action to cement my understanding.

I ran `dotnet new webapp` to setup a new ASP.NET Core project. In the project's Program.cs file I added this contrived endpoint:

Expand Down Expand Up @@ -71,6 +71,6 @@ My log message now appears in the LogManagement.AppExceptions table and I get mo

![Exception and Message Template](/images/logging/exception.jpg)

One other tip, since the message template does look like the `string.Format` method it might also be tempting to use numbers for your parameter placeholders. This was common practice for `string.Format` i.e. `{0}`. However, as you realize now, having a bunch of different log message types with a property whose name is `0` isn't going to benefit you.
> Since the message template does look like the `string.Format` method it might also be tempting to use numbers for your parameter placeholders i.e. `The error is {0} at {1}`. It won't benefit you to have a bunch of different log message types with a property whose name is `0`. Also keep in mind that templating works on the **order of the parameters**, not the names.

It helped me to see this for myself in Log Analytics. If you've never seen this before either, hopefully it helped you too.
Loading