shutterstock_553689451.jpg

How Logging Helps Make Apps More Maintainable

Danny:Hello and welcome to the ThreeWill podcast. This is your host Danny Ryan and I’m here with Tim Coalson. Tim, how’s it going?

 

Tim:Good, how are you doing today Danny?

 

Danny:I’m doing great. We’re wrapping up the day here, a little past four. I appreciate you taking the time to come and sit with me for a little while.

 

Tim:What better way can I spend February 14th, Valentine’s Day?

 

Danny:You don’t have to hold my hand though man.

 

Tim:Are those chocolates for me?

 

Danny:You’ve done something sweet for Sonya, right?

 

Tim:Of course.

 

Danny:You’re already done with doing something?

 

Tim:Just my mere presence.

 

Danny:Your mere presence? Tim, let’s talk afterwords. We’re going to have to talk a little bit after this, okay?

 

We wanted to talk today about logging, the exciting subject of logging. What I wanted to find out was how are you using it on projects, what are you doing with it? Just get me up to date on what’s going on here.

 

Tim:I am and have been working probably for the last year on a public site for a tax and auditing software company. We are working on a support site, and we found that logging could be really valuable to us. We initially had logging for just normal debugging, things that when we call services and such, when we could capture errors and things like that.

 

We sort of have gotten a broader vision of how logging can be used, not only just for debugging but also to start to capture some analytic type information. Part of our project has been the creation of a logging framework with an associated viewer and a lot of configuration options to be able to look at different parts of the application, either in standalone log files or collected together in a bigger file.

 

Basically the idea is that from the time a user logs on, even if they’re not authenticated using a session id, we can see exactly what that user did, how they used the system. There’s tools out there to do some of that as well, but we’re doing this at a logging level to be able to see how they navigated through parts of the application and based upon their activities.

 

For example, if they did a search in our knowledge base; did they have to page through the results or seemingly did they get their answer on the first page? Do we see that once they did their search, then they had to page through the results to find what they were looking for; which might indicate that maybe the relevancy in our search needs to be tweaked.

 

Danny:Are you using this logging for when you have issues on the site and people raise up that there is a problem that they’re having with the site? Are you using this logging tool to try to reproduce the error that they’re getting?

 

Tim:Right, it’s really being used for all these things we’re talking about; not only analytics but trouble shooting. For example we’re generating log error reports on a daily basis, that way an administrator of the log can go through and look and see all the errors that were raised in the application during the day.

 

If you start to see certain errors happening multiple times, then certainly you start to see that’s a good area we should do some research in to see, “Is there is a problem with the application, or is there a path that the code is going down that we didn’t anticipate and that’s causing problems?”

 

It’s really kind of a proactive way that even if users don’t take the time to submit a call or submit a ticket on the site, it’s a way for us to kind of proactively see, “Wow, maybe there’s a problem here that we need to fix.”

 

Danny:You use the word framework, are you using any open source frameworks for this?

 

Tim:Log4Net is the foundational tool that’s being used. Then part of the project team has written wrappers around that to be able to configure that. We have configurations screens where log administrators can go in and they can establish for each part of the application what level of logging do we want to see.

 

Do we want to see an info level logging, which is kind of a high level view of what’s the user doing on the site? Do we need a debug level? Typically, we run in an info level where it’s pretty high level view. If we start to see there’s issues or want to see at a lower level exactly what’s going on, we can set it a debug level.

 

We have statements scattered throughout our code that are showing the values of certain objects throughout the life cycle of certain transactions that happen in the application. That way you can kind of see what was going on at any given point in time and any error information, if there is an error that you’re trying to trace down.

 

Danny:I’m sorry, ever since you used the word wrapper I have this stuck in my head; wemote access WAIN wapper. I don’t know why I think Elmer Fudd saying that, I don’t know what part of my history that comes from.

 

Sounds like the team is utilizing this pretty extensively. Are you using this on other projects or is it just this one project?

 

Tim:We have used it on other projects; within our applications, oftentimes we’ll create a logging table where we log any kind of exceptions there or log any information there that we want to be able to track.

 

Matthew Chestnut, one of my coworkers, he’s had a much longer history, maybe because he’s a lot older than me; much bigger history with logging. He has some nice tools that he uses, DebugView and BareTail so that you can actively watch the logging as it occurs and see it as it scrolls; which is nice when you’re trying to either validate that your logging makes sense, that it tells a story, or just as you’re running the application.

 

With this BareTail tool you can turn on highlighting so that anything with the word error will show up in red, so you can easily see an error as it scrolls across your screen because it’s going to be in a bright red font. It’s just a nice way to, as you’re working, to be able to see maybe even unexpected errors that you don’t anticipate that are being caught with your exception handlers that are catching these errors. Nevertheless, you can see them in the log and know that they are happening.

 

Even though it may not show up within the application screen, the user may not be aware of it, which hopefully they’re not seeing errors; behind the scenes there could be errors that are being thrown and caught. These tools allow you to see those real time as you’re testing.

 

Danny:Is this something just our team is going to use, or is this something that they were transitioning over to them to use as well? Are both teams using it?

 

Tim:It’s been a joint effort. Actually both teams were using it, but on this project itself it’s become a lot more formalized. We’re actually building this whole framework around the loggings, so that it’s not only a developer tool but really becoming a system administration tool where a person will have the assigned role of going through, reviewing these logs on a regular base to determine are there things that we can see that are happening that we need to proactively fix before we start getting calls from customers.

 

Or are there other usage patterns, that from an analytic standpoint, we can learn from to better organize the data on the screen to make the most important things that our users are hitting? Maybe make those a little bit more visible.

 

Danny:Are you guys using an analytics tool at all?

 

Tim:The long term view is to actually purchase a product so that essentially all these logs that are being written to on the individual front-end web servers can all be collected in a single location and a lot more analytics done on the data.

 

Danny:Cool, good stuff.

 

Tim:It’s interesting. Sometimes your vision of logging, at least for me, is expanded. We’ve used Google Analytics obviously in the past to capture certain events. This is just another opportunity to collect more information within the application and have it available to be able to look at; slice it and dice it, and kind of see what’s going on.

 

Danny:This has been nice because this project is a sustainment project, so it’s a multi-year project. Typically we’re building out these applications and then transitioning them over. This is one when we’re supporting the application over the long term.

 

Tim:We’re being part of the whole evolution from the beginning, where it was really more of a debugging tool, to now where it’s being evolved by the entire team to be more of an application into itself that we can get a lot of value out of.

 

Danny:Excellent. Anything else before we wrap up?

 

Tim:I think that will do it. I’m looking at that chocolate over there.

 

Danny:You got some chocolate? Where? Thanks Tim, thanks for taking the time to do this.

 

Tim:Have a good day.

 

Danny:You betcha, take care. Thanks everybody for listening. Bye-bye.

 

Danny RyanHow Logging Helps Make Apps More Maintainable

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.