When you play with different configurations for Serilog or try to add another sink you may run into problems. If you are out of luck your application crashes without the slightest notice - Serilog silently eats it's own errors. In such cases you have to dig a little deeper into Serilog to find out what’s going on.
Seq and Serilog can be easily combined and when we keep in mind some of the important aspects of writing log messages, we can fully leverage the benefits of both tools. Today I will show you some features I find particularly helpful when working with Seq.
Serilog is a great tool to write structured log messages. To fully profit from the structured part you need to write your log messages in a certain way. Otherwise you lose most of the great features and could use any other traditional logging framework. Luckily there are only a few simple things you should keep in mind and I will show you today what those are.
As I explained in the last posts, log messages are not just strings but have an inner meaning. When we use Serilog to write structured log messages we make them explicit to query them later. The tool we want to use to search for a specific orderId should give us this capability without the need to write all the code from scratch. We therefore need a tool that understands log messages and, if possible, even Serilog. One such tool is Seq that I explain in this blog post.
As I explained in the last post, creating JSON documents with Serilog is easy. But to make something useful with the log messages we must be able to query them. When I think about storing JSON documents then RavenDB is the first system that comes to my mind.
As a .Net developer you can choose from a variety of logging frameworks. All are more or less built to mitigate the shortcomings of the built in tracing framework. While System.Diagnostics.Trace has some helpful concepts, it misses many basic features most other logging frameworks can offer out of the box.
Log files could be a great place to find the answer on what went wrong in our applications. They should contain all the necessary information to understand the state of the application before and while the error happened. Instead most log files are giant collections of data without much structure and even less meaning. What is unfortunate in one single application is a problem as soon as multiple applications need to work together.
As a little distraction from writing I was procrastinating on Hacker News and Reddit. The blog post “Why are we interviewing Developers by asking Architect questions?” caught my attention and got me thinking about the term "maintenance developer". Those mythical species of developers who are so insisting that their work is so fundamentally different from all other things that developers do. As Ted Winslow points out they should not need to know anything about architecture. Others think they don’t influence the code and therefore don’t need training. Visiting a conference is a waste of time, then all they do is maintenance…
Geofences are a nice feature that can help you to focus on important things based on your location. At work you care for other things than in the supermarket. Showing your groceries list is a help there, but at work it's a distraction at best. Applications that support geofencing can help us when the technology is used wisely.
This year's NDC Oslo was once more a remarkable conference. Great speakers doing 9 parallel tracks for 3 days crated an enormous amount of content. So far I can give you an overview on the sessions I attended. It will take me some time to catch up on all the other sessions I want to watch. Those sessions will be part of another post in a few weeks.
The videos of the NDC can be found on Vimeo. I can highly recommend the presentations I mention in this post. With many more to watch I'm happy for any recommendations.