But who wants to have to remember to log it every time? Diagnostic context logging to the rescue, specifically the mapped diagnostic context. Think about what other detail might be useful – for example, HttpWebRequest details. Know who the user was is the sort of context that is priceless in being able to quickly resolve an issue. When it comes to debugging a production issue, you might have the “Creating a Foo” message thousands of times in your logs, but with no clue who the logged in user was that created it. When you log objects as JSON and use Stackify’s Retrace tool, you can get some nice details like this: Retrace Logging Dashboard JSON Viewer Logging More Details with Diagnostic ContextsĪnd this brings us to one last point on logging more details: diagnostic context logging. Take a look at the following, oversimplified example. You could just put a try / catch around the entire thing and handle the exceptions (which you should) but it doesn’t tell you much about what was passed into the request. Let’s pretend that you have a process that you want to add logging around so that you can look at what happened. Here are our guiding principles on doing that. You want to log as much relevant, contextual data as you can. If you’re tasked with troubleshooting an error in production, and/or it is happening for just one (or a subset) of the application users, this doesn’t leave you with a lot to go on, especially when considering your log statement could be a needle in a haystack in an app with lots of use.Īs I mentioned earlier, logging is often one of the few lifelines you have in production environments where you can’t physically attach and debug. Sometimes, they even do some more proactive logging, like this:īut generally, statements like that don’t go a long way towards letting you know what’s really happening in your app. The exception will likely have a stack trace so I know roughly where it came from, but no other context is logged. I’ll give the developer credit at least they are using a try/catch and handling the exception. I’ve worked in a lot of shops where log messages looked like this: Also, if you haven’t used Prefix to view your logs, be sure to check it out! Start Logging All the Things! In this post, we’ll explore these best practices, and share what we’ve done to address it, much of which has become a part of Stackify’s log management product. Also, to find new ways for our logging and exception data to help us proactively improve our product. Consolidate and aggregate all of our logging to a central location, available to all devs, and easy to distil. Log as much as we possibly can, to always have relevant, contextual logs that don’t add overhead. why can’t this user log in, or why isn’t this record processing?Īt Stackify, we’ve built a “culture of logging” which set out to accomplish these goals: Sure, APM tools can alert you to memory leaks and performance bottlenecks, but generally lack enough detail to help you solve a specific problem, i.e. Once you’re working on an application that is not running on your desktop, logging messages (including exceptions) are usually your only lifeline to quickly discovering why something in your app isn’t working correctly.
0 Comments
Leave a Reply. |