In this video, learn what diagnostic logging is and what capabilities Azure has to work with it.
- [Instructor] Next let's talk about another amazing capability of Azure, which is diagnostic logging. What is diagnostic logging? Azure provides built in diagnostics to assist with the debugging of an App Service application. This is really important because you're going to deploy things inside of Azure and the server it's running on you can't even touch it. It's far away, you don't even know where it is for the most part. So how do you go about diagnosing things on that server? So Azure App Service, as you may know, is a service for hosting web applications, rest APIs and mobile back ends. Now you can develop in your favorite language be it .NET, .NET Core, Java, Ruby, NodeJS, PSP, Python, et cetera. And applications can run on both Windows and Linux-based environments. So you need good tools to diagnose problems, right? That's diagnostic logging. And it can be thought of in two parts. Number one, web server diagnostics. And number two, application diagnostics. Let's talk a little bit about both of these before we see them in action. Application diagnostics, so this is all about the Systems.Diagnostics.Trace class that I've already talked about. These are the traces that we had put in when I was talking about application insights. Well, App Service itself has a lot of capabilities to make use of these traces as well. So you can trace errors information and warnings. And these errors information warnings can be viewed in numerous ways and they're tweakable via configuration. Certainly the example you see over here the system.diagnostics section is one possible way. And this information is viewable through the output window Visual Studio. Or it can be streamed to log analytics or it can be seen streamed through the Azure portal, Azure CLI, right inside of Visual Studio, when it is running in Azure, and so on so forth. Now let's talk a little bit about Web Server Diagnostics. Well, there are different categories here. Number one, let's start with detail error logging. What happens when you run into an HTTP error? Have you ever seen an HTTP 500 and wondered what caused it? So this is an interesting paradox we note in detail. You want to show the user that an error occurred, but you don't want to leak sensitive details. So the detail information can be caught using detail error logging. And it may contain information that can help determine why the server returned a particular error code. Similarly failed request tracing. That's the detail information on failed requests. Including an entire trace of the IS components used to process that request and the time taken in each component. This is very useful when you are trying to improve site performance or let's say you run into an HTTP 500 and you want to know exactly what is causing that error, be it your code or not even code that you wrote but you depend on. Say, parts of the .NET framework. That is failed request tracing. And then finally you have web server logging. Which is information about all the HTTP transactions that are logged out using the W3C extended log file format. This is very useful in say site metrics or analytics. And a number of requests that are handled either say from a particular IP address, you can understand all of that information from web server logging. Now if they sound familiar it is because they are. They are equivalent to what you might already be used to in on premises IS. In an on premises IS you enable and disable these by editing the web.config. And while on IS it recycles the application pool. In Azure, tweaking these does not recycle the app domain. In Azure you simply enable and disable them in the settings slash diagnostic logs area and this is what it looks like. Now it is worth mentioning that currently only .NET application logs can be written out to blob storage. Java, PSP, NodeJS, Python logs currently can only be stored on the file system. Of course if you change the keys for your storage you're going to have to reconfigure your .NET application so it can continue writing to the blob storage as well. That's understood. But if you want to write to blob storage for now .NET is what you need to stick with.
- Using Application Insights to track and record exceptions
- Viewing exception details
- Diagnostic logging
- Viewing activity logs in Azure Monitor
- Assessing service health in Azure Monitor
- Displaying parameters from VMs and containers
- Tracking network-related assets
- Estimating your bill
- Viewing security and performance recommendations