325. What Data Should We Log/Trace And What Should We Ignore

How do I know what to log in my application? What information is important to capture in logs? How do I avoid security implications in logging? Should I log to the console in a web app? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:05

Logging lets us know where the problems are happening. It also lets us see how our app is being used. But if you aren't careful, logging can actually make it harder to understand where the problems are occurring and how your application is being used. So let's talk about how to properly implement logging in a way that will actually benefit our application in today's episode of Dev Questions. Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about how to properly implement logging. And let's start with an illustration. Back when I was a very new IT director at a small college, I was working with my network administrator to implement server logging. Up until that point, we didn't have any central logging. Errors were discovered by the users or, you know, but we stumbled across them, or maybe if we looked through the event viewer. And we had a full network with Active Directory and Exchange Server and SQL Server and File Servers and all the rest. So we we found this software that would centrally manage all these logs. It would track the different things going on in our servers. It would make sure that it looked out for things like, hey, you got low disk space on this server, or hey, this server is hitting a very high CPU all day long, or we've got a bottleneck in memory here, or whatever the case may be. We're throwing exceptions or whatever. So this software was great, and it could do so much stuff. We went to training, we we figured out how to make the whole thing work correctly, how to get the most out of that software, and then we implemented it in I think it was like 20 servers. Um and so we we implemented all these different servers, we had it, we set it up and configured it, so we made sure we looked at all the different errors, all different issues, and made sure that we were tracking all the things we needed to in order to have a really good bird's eye view of what's going on with the entire network. And we barely ever used it. And here's why. Because the first day, my network administrator was getting the emails for all of the errors, all the big problems he'd get the emails for. And his inbox was flooded to the point that he created a rule that said, hey, if it's coming from the logging set server, put it in a different folder because I can't even see my normal emails. Then what do you think happened? At first, we started going through those emails, but then some of them were like, hey, that that you know, that server is getting low on disk space, but we knew that, and that's not some address, or hey, that server is kind of you know going at 80% plus of CPU usage, but that's a good thing. We want it to be there. And so we started seeing all these issues where for some servers that would have been an issue, but for others it's not. And so we started ignoring issues. But then we had a hard time finding the issues that were really issues. So what we found out is just because an issue seems critical in a vacuum doesn't mean it actually is. And if you're not gonna do something about it, then it's not actually an issue. So either critical alerts need to be dealt with or they need to be downgraded. Otherwise, you drown out the real critical alerts. And that's really hard to do because when you're looking at things, you're saying that is an issue. But if you're not gonna deal with it, is it? I mean, it may be something that you want to address. It may be on your, I would love to take care of that list, but unless it's an issue you're gonna say, yes, I'm going to address that now, it's not really something you should have in your critical alert list. And so what happened was his inbox was constantly full of alerts. And we just never seemed to do a good job of figuring out which ones are critical, which ones aren't. And so, yes, we found a problem when a user reported something, we could go to the log server and go, oh, yep, that issue was there. We got the alert for it 18 times, but it got lost in the middle of the thousands of other alerts that were going off. And so just because those things seemed like they should be logged doesn't mean they should have been. We should have been logging just what we're going to fix. So let's talk about how to set up logging that works. Now, we're talking more about logging inside of your application. So this is not exactly about server logs, but they the things still apply. So let's talk about how to set up the logging that actually works for you. Number one, only mark issues as critical if you absolutely need to do something about them. Too many people say, well, that's a big deal. Is it though? Again, if it's a big deal but you don't do anything about it, it's not a big deal. It that's just information at that point. If you're not going to act on it, there's no reason to make it a critical issue, make it an informational issue. And yes, I know sometimes you may go, but that's that's that's important. It's only important if you do something about it. That's really what it comes down to. It doesn't matter what you say, it's what you do. This is a fact for all of life. If it doesn't matter what you say, it matters what you do. So if you say this is critical, but then you do nothing, it's not critical. So be very careful to only bubble up things that are critical, things that you're actually going to do something about. Number two, only log errors as errors if they're unexpected or need to be addressed, such as, you know, like, hey, this service has crashed. Okay, that needs to be addressed. And that's that's an error that needs to be addressed. Um, if there's an exception that happens, but it's not something we're gonna address, then don't log it as an error. Um, even though the error logs are the ones that take the exceptions. And you might go, well, I have to put them there. No, you don't. So you don't need to log the network connection was went down for the user. You don't need to log that unless you need to know, oh, the network is going down in this area. For example, if you have microservices and two different microservices, maybe one's an API and the other one's talking to the API, maybe that network connection is all internal. And if that goes down, yeah, you should know about that. And that would be something critical. But if the user is on their laptop and they go through a tunnel and they lose the connection to the cell tower and it comes back up afterwards, that's not an issue that you need to be logging. So even though it might throw an exception on the user's machine, even though it might be triggered as an error, you need to go, that's not really an error. And so this is where being granular about catching these exceptions and going, this one's important, this one's not, is important. If you're doing a uh a try catch and that's catching EX, you know, the raw exception ex where you're not specifying which exceptions and you're just saying, hey, make every one of these an error, that's not very efficient. It's gonna clog up your errors and your logs. So maybe at first you would do that, but then figure out, oh, we're getting these network drop-offs. And those network drop-offs aren't really a big deal. Well, then in your catch, have another catch before your generic exception ex that's like network exception or whatever it is that's the actual network error, catch that one and maybe let the user know, hey, you don't have a network connection right now. But don't log that. There's no reason to log that if you're not going to do something with it. Number three, only log warnings that are precursors to actual errors or critical issues. If there's something that is an indicator that something is going to happen in the future and it will be a major issue in the future, that's a great warning. So a simple example might be, hey, I noticed we're getting low on disk space. Okay? That's something that should be a warning because that's leading up to, hey, we're out of disk space. So, yes, that could be a good warning because, again, you're going to do something about it. Maybe you won't do something about it right away, but you'll do something about it in a week or within the next few days as you get time, because that warning let you know before it became a critical issue. So warnings are good to have, but again, don't log things as warnings that aren't precursors to actual errors or critical issues. If it's just a, hey, the user doesn't like us, or, you know, hey, the user put bad data in, these are not warnings. This is just information that you've elevated wrongly to a warning level. So again, it has to be based upon something that you're going to do something about. If you've noticed a theme so far, this is what logs are for. Logs are not for the pack rats, the digital pack rats who want to store all this information. That's not what logs are for. Logs are for doing something with. And if you're not doing something with your logs, you're not using them correctly. So, number four, understand your application's importance and adjust what you capture and where. What do I mean by this? Well, not all applications are created equal. Some applications are mission critical applications. I worked on a software as a service for a company that their whole line of business was a software as a service. If that software as a service went down, then we didn't get paid. All of our customers wouldn't pay us because we're not actually providing them what they need. The whole business would shut down. That's mission critical. And that application was logged differently. Now, I've used other or built other applications where it supported the development staff, where it made deployments easier, or it made cleanup easier, or it made simple tasks, documentation easier. These are not important applications. These are support applications that we could get by without or that are nice to have, but no one is coming in the weekend to fix. So you need to adjust your application's logs accordingly. So just because this application has a critical failure doesn't mean it's it's crazy important to do. Again, you're not coming out on a Sunday to fix this application if it's not an important application. So you need to understand your application's importance to the organization and adjust your logging accordingly. Also, where you log. Because there's going to be the central place that everybody should look at. Again, read your logs. Um, everyone should look at that tells you what's going on, what's critical, what's an error, what's a warning. Those are things you should be looking at probably on a daily basis. You should be aware of what's going on and be fixing those things because they're priorities. But if you have minor applications, they probably shouldn't go in the same system. Maybe you should be logged to a text file, or maybe you should log to a secondary server that you check once in a while when you have time. When you're looking to make a change to a secondary system, you also look and see, hey, are there any critical or error warnings in there that I should address as well? So where you log is also important because also logging is expensive. And you don't need to be logging lots of messages from non-critical systems into your main logging system that's going to cost more money. And again, it's going to clog up that main system with a whole bunch of critical error and warnings that aren't actually critical errors or warnings that need to be dealt with right away. So make sure not to clog up your systems with too many false positives. Try very hard to have zero false positives. Number six, do not capture information you're not going to act on every day until unless you're investigating an issue. Okay. So when you're capturing information, don't gather information you're not going to act on. So if you're saying, well, I need to know what the user does when they use the application, do you? Or is that more like a testing thing? Or is that more like a sometimes thing? And that's where you have things like information logs where you can turn those on just for investigating an issue, or just for um, you know, trying to figure out how users are using your application. Not all the time. So don't log information, don't capture things that you aren't going to act on. That also means what types of data you capture. So this might be, you know what? We need to know that we're out of disk space, but we don't need to know what you were doing when you found out you're out of disk space. We don't need to know that information. We just need to know that the system went, hey, I try to save a file and we're out of disk space. That's all you need to know. You don't need to know who was who was trying to do something. That's irrelevant information. Capture the information you're actually going to act on. And again, you can use those lower log levels for when you're investigating issues or investigating how the system is used, et cetera. You can turn those on. Maybe you log them somewhere else, or maybe just make sure they're filtered out of the main system and only used for those investigations. Number seven, do not save data beyond when you will reasonably use it. I have found that in most cases, 30 days is about all you need. Because if you get beyond that, you're not actually using the data. First of all, if you have a critical issue that stays in the critical issues list for over 30 days, you're not using the critical data system correctly. You need to have addressed it before now. That needs to be turned into a ticket that needs to be starting to be worked on right away. So if you have data for more than 30 days, why? Why is it there? Why is it not converted into an issue? For the most part, delete it after 30 days. That's all you need at most. So you can have a log system that turns over quite frequently that even handles things like hey, we had Christmas break and we're off for a week. No problem, because you have 30 days. You still have 21 days of usable data. So there's still a lot of data there for you, even if you have breaks, even if you have people go on vacation, even if you have both combined at the same time. Like 30 days is a lot of data if you were acting on it. The times when I've seen people say, I need more than 30 days, is when they are not acting on it and they are only looking at it every once in a while. And they say, Well, I need to know historically how things are working. You should have been fixing these problems, so historically shouldn't matter, because you should have fixed these problems by now. So, therefore, if you have a critical error or critical issue that's happened over 30 days long, then you're doing something wrong. Or it's it's in a ticket and you're trying to fix it. But at that point, it's already on tickets. So why do you need it in a logging system? So try not to save data beyond when it's reasonably useful. Otherwise, what happens is you become a digital pack rat and you got so much information there that you just never use it, but it just keeps getting more and more expensive to store. And it can actually cause some other problems where you are storing things beyond when you should. So don't save data beyond when it's reasonably useful. Number eight, do not log sensitive data unless it's absolutely necessary. This is one that often trips people up, and this is where a lot of security breaches can come in because you're logging the sensitive data and taking it out of a secure system and putting it into a less secure system. So, first of all, your logging system should be pretty secure. And then you should also try not to include anything that's of person identified information or other sensitive data in your logs. Yes, there's exceptions. Yes, there are times when you might have to, but in that case, you need to make sure that your logging system is locked down secure, and it's also in compliance with all the regulations around forgetting a user if they ask you to. That means you need to go through your log system and clean out those logs, referring to that user or change that data. So being compliant is harder if you're logging sensitive information. So maybe try not to. And again, these regulations are there for a reason, because people are putting sensitive data in systems that aren't as secure because they think, well, it's just a logging system. Or it's not as protected because, well, everyone has to have access to it, right? And then next thing you know, you're leaking sensitive data and endangering your users because you were sloppy. Don't do that. So number nine. Number nine is don't log to the browser's console in production. This is one where you know, if you're using something like uh React or Angular or Vue, uh, or even like Blaze WebAssembly, where you are front-end fully. Try really hard not to put console log statements there. Use an actual logging service. Now, sometimes that logging service is not available, where maybe you have a network issue or other thing where you need to log or tell a user in some way, try and tell the user directly. Don't try very hard not to put it into the console log. We really don't want to have to ask users to open up the developer console, look at the actual console message, and figure out the message says. That's not good. So if we're not asking them to do that, then why are you putting those messages in there? Because the other thing is those messages can leak information about what's going on. Now, everything you do in the browser is going to be unsecured, or at least unsecured as for that person. So if that person logged in and they have their credentials, well, sure, they have access to all of their things. But that also means that any code that runs in the front end is going to be completely exposed to the user. They can read all the code, they can read all the data. So it's not quite the same as logging like a C sharp applications information and displaying that. You know, if you have a Blazor uh web app where you're showing the server side logs, yeah, it's more that's more information leakage than a console log would be. But still, don't put it in the console logs. Not if you can help it. There are exceptions. There are exceptions. You know, no pun intended. But there are exceptions to that rule. But for the most part, try not to put um errors in your console. Try and expose it to the user or send it to a logging system if you're going to act on it. If your logs have too much information, they become useless. If your application treats too many things as important, nothing is important. And if you aren't addressing the actual issues as they come up, you're going to hide the real issues. You need to make sure you're only looking at logs you'll actually act upon. That's how you protect your applications. That's how you improve your user experience, and it's how you ensure you'll actually get value out of your logs. Thanks for listening. As always, I am Tim Corey.