From the course: Microsoft Azure Developer Associate (AZ-204) Cert Prep by Microsoft Press

Enable diagnostics logging

When you're running a web application and you have to be prepared for any issues that may occur from errors like HTTP 500 errors, like users telling you that, hey, we can't access the website. This is something that you need to be prepared. And the app service diagnostics, it's an intelligent, interactive experience that can help you troubleshoot the issues that your applications will have. Because if you don't have logs, if you don't have any kind of logging experience, it's going to start to be like a guessing game, to be honest with you. Hey, maybe it's this, let me try. Maybe it's that, let me try that. Sometimes based on your experience, you might get it easier. But if you don't have that much experience, you might go in and roaming in a way that it's just totally the wrong way to go through, because the problem is in some other place. The App Service diagnostics will help you so that you can, in a more easier and quicker way, you can troubleshoot what the issue is. And of course, when you troubleshoot and you understand where is this problem, is coming from, of course, it will be much, much, much easier for you to fix the actual issue. We can store several types of logs. So the first one that we have here is application logs. This is logs messages that are generated by your application code, the messages that can be generated by the web framework you choose, or from your application code directly if you are using a standard logging pattern in that language. We also come with categories like critical error, warning info, debug trace, and then you can select how verbose you want the logging to be. So maybe you don't want to store all of them, maybe you just want to start, to store some that start in like warning, all the other ones, the lower tiers like traces, debug messages, it doesn't matter for you. Just an example. Then we also have web server logging. This is the raw HTTP request data using the W3C standard. Then we also have detailed error messages. These are copies of the error pages that you would have sent to the client browser. For security reasons, the detailed error pages, they shouldn't be sent to clients in production, but the app service can save those errors and then just generate a fancy message error page with not that much information to the users. We also have failed request tracing. This basically includes details like tracing information on those failed requests that we have done. And then the deployment logging logs from when you publish content to an app. So the deployment logging happens automatically. And there's no adding other configurable settings that you have done on this. It's also important because I already had applications that they were running super fine until one day or DevOps process deployed. Got a code like everything is good, but yes, we had some issues. The deployment and what saved us was this deployment logging and we could understand what the problem was. Then you also need to store this data somewhere. So you can store this in the App Service file system debug. This will be staying there for some hours after this. If you want, you can set up something that will actually store this in a storage account, log analytics workspace, or actually in the file system, but then you can tweak how many days or how much time do you actually want this there. You might have some standards to follow that this data needs to be stored like forever or for some days, some years, I don't know, something like that. So, yes, you need to find alternatives for this, like storage accounts and then putting lifecycle management on that storage account or using a log analytics workspace for that. So let's go do a demo. And let's see how we can easily enable application logging. So now, we want to enable application logging. And we all know how important logs are, because if we know we have some issues or challenges with our applications, that's the first thing that we go through, hey, where the logs? And we know we need the logs to understand and to debug, where is this issue coming from? If you don't have logs, sometimes it's kind of we start like that guessing, is it this, is it that, is it that? And we just try based on our experience. Sometimes it's easier for some people that have more experience, not so much for the ones that don't have that much experience. But with logs, we go there and it's way more clear where the issue it is coming from. So to debug the issues, it's like super important to have that. So how do we do this? So if we go on our resource group and we open here our web application, which is this azcontoso-demo that we have here, we can now scroll down and under monitoring, we have here the option which is the last one called App Service logs. And this comes off by default. So you actually don't have this. And we have here options for like file system. And now I can say here, you can see here, this is the limit that restricts the file. So we are restricting this to 35MB. That means that it will not store more than 35MB. And then also the retention period that we can put in here. So let's imagine, look, I want this to be kept for 30 days. And I want this for like 50MB. And that's it. You just save and you're good to go. So now you have this and you have your FTP and FTPS credentials in order to get there. It's, in my case, for security purposes this is grayed out, but you could always check this out on your own versions, okay? But yes, that's it. Then you can just go and you can just access those logs. And another option that we have is this diagnostic settings, too, where we can also configure, and we can see here all those things that we have here. And we can configure this to go to a storage account, to a log analytics workspace, or even a partner solution. So in order to do this, it's just this link, add diagnostic setting. And now you have to select which categories you want to send, and where do you want to send. Like hey, I want to send this to archive in a storage account. I have like a random storage account that I have here. It's actually not the best, but let's just use that one. And I just need to take the things that I want, and then just give a name here like demo. And you could just store now this diagnostic settings, okay? So if you just save this, this means that now all those logs on those categories are going to be archived in this storage account. Instead of a storage account, or in addition to that storage account, because you can do more than one, you can also say, hey, I want this in this log analytics workspace that we have here, or I could choose another one that I have here with all my data. So you could just do this. Just be careful with all the things that you send if you really, really need them. And with log analytics, because log analytics can be a little bit pricey. It's a great service, but it can be a little bit pricey, specifically if you start to send like every single log because sometimes you actually don't need all those logs to be hosted in log analytics workspaces. But yes, if you do storage, storage is quite cheap. So you can do that one.

Contents