Hi All! In this post, we’ll see what’s the difference between “standard” and “structured” logging and how the latter can help us tracing down issues in our systems.

But first, let’s begin with a question. Ever had to go through countless of log messages to find a single tiny entry?

Then you know how it feels like.

Standard logging represents the simplest form possible. It’s just a simple message, possibly correlated with a timestamp and probably a few other pieces of data.

"creating customer 123..."
"an exception has been thrown by..."
"something, somewhere, went terribly, terribly wrong"

Maybe, if you’re lucky you also get a bit of stack trace.

Adding logging to an ASP.NET application is quite easy, although configuring it properly can be sometimes tricky.

Knowing what to log instead is the real deal. We don’t want to lose important information but at the same time, we have to avoid polluting the system with unnecessary messages.

Now, the problem with _standard **_logging is that searching for specific entries can become difficult. Very difficult, especially when our system has been online and used for a while.

Filtering and potentially doing some aggregation is doable but the quality of results is questionable. There are multiple tools that can help us with this, like Grafana and Splunk (and do much more than that, to be fair).

So what other option do we have? Well, we can move to structured logging instead. What’s the difference? Well basically we’re enriching the log entry with some additional data, regardless of the actual text message.

These fields can then be used later on to filter the entries, create aggregation, stats and charts. All this data is of course extremely useful, helping us monitoring and keeping under control the health of our systems.

Now, obviously, if your application is creating just a hundred messages per day, you won’t find much benefit from all of this. Just come up with a decent Regexp and you’re good to go.

This of course doesn’t mean that you’ll have to start throwing more messages just for the sake of it. All the opposite.

But if you’re orchestrating a large microservice application, with a lot of moving parts, possibly with complex architectures like Event Sourcing, then you want to be careful.

If we’re being diligent and keeping field naming consistent, structured logging will help us tracing down the flow of our transactions amongst the different services. Yes, it can be hard, especially when there are multiple teams working on separate microservices.

In this case, things like Trace identificators are the key solution to our problem.

That’s all for today. Next time we’ll see some examples and how to leverage structured logging in our ASP.NET Core application.

Did you like this post? Then