Azure has a plethora of features and most of them remain unexplored or unused by a number of developers, though they are extremely useful and provide value. A few of the important ones I came across are listed here:

• Azure in your pocket: We will start with a cheesy one. Yes, Azure in your pocket. Now Azure is available as a mobile app, and you can virtually carry your Azure subscription wherever you go. You can keep track of your Azure resources on the go and stay connected—anytime, anywhere. The following image shows a glimpse of the Azure mobile app:
  

• Advisor: In the left panel of the Azure portal, there is an item called Advisor. Although it's free, it's a relatively lesser-used and talked about feature of Azure. It's completely free and it provides real-time advisory services on your Azure resources, based on how they are used. Just click on the Advisor and it will give security, performance, cost, and availability recommendations. The recommendations can also be downloaded in CSV or PDF format. Here is the teaser of Azure Advisor:

• Security Center: Just like Advisor, there is a Security Center option in the left panel. This is a great and free feature of Azure. It does threat detection all the Azure resources in your subscription and gives pointed recommendations. It also lets you know of any security incidents that occurred with your resources and threat assessment reports. There is a paid plan which has advanced threat detection but the free option is a good starting point. The following image shows the Security Center:

• Activity logs: When I have worked in a team that is working on Azure, there have been instances where I am working on the web app and some other team member accidentally changes the configuration, or maybe restarts or deletes a resource, and I have no clue what happened. I have myself been the culprit, modifying the configuration while the performance test was running, which restarted the web app. Azure has a solution for these kinds of situations as well. Every action that a user does is logged in the activity log of the resource you are working with. So, next time you encounter something like this, just go and see the activity log, as shown here. In the Azure portal, go to the resource you wish to see the activity log of. On the left panel of the resource, click on Activity Log. You can also apply filters and choose the time duration for which you wish to see the activity log:

• Diagnostic logging: If you are running into issues in the app deployed in Azure and do not know what's going on, enable logging and Application Insights in your app. We looked at Application Insights earlier. Logging can give us details such as failed request tracing and detailed error logs. You will see two options for Application Logging—Blob and Filesystem. As the name suggests, logs are stored in blob and filesystem. Filesystem logging is enabled only for 12 hours, as there is a risk of logs eating up memory. The following image shows the diagnostic logging configuration:

• Diagnosing and solving issues: This is another cool feature in Azure. If you run into issues or suspect something is going wrong in your App Service, Azure provides very good diagnoses and a fix for the issues. It is able to clearly identify whether the issue is due to a platform or application code issue. It diagnoses a variety of problem categories such as web app down, slow web app, high CPU usage, high memory usage, web app restarted, TCP connections. It has a chat interface making it easier to use. Just click on one of the problem categories and it will do the analysis on the app for the last 24 hours and share the graph and findings, which makes it extremely easy to identify the issue. It will also give recommendations if you need to scale out your app. Also, you can do a health checkup of the resource on demand, which gives a single view for application errors, performance, CPU, and memory usage. This is definitely a very handy tool to use for diagnosis. Here is the screenshot for diagnosing and solving issues:

• Diagnostics as a Service (DaaS): Yet another great troubleshooting tool for developers is DaaS. When you open the diagnose and solve issues blade for your App Service, there is a panel on the right displaying a number of links:

Each of them is a great diagnostic and support tool in itself, but we will focus on DaaS. I would highly recommend you explore each of these links. Coming back to DaaS, this is what it looks like:

It has support for ASP.NET, PHP, and Java applications. We will select ASP.NET as our application type and when we do that, we will see ASP.NET-specific diagnosers such as CLR Profiler, Event Viewer Logs, Memory Dump, and HTTP Logs. Based on the diagnosis that we need to do, we can select appropriate options. I generally check everything whenever I am doing diagnosis. Memory Dump analysis can be great to identify memory leaks, but the dump needs to be taken when you observe constant high or increasing memory usage. Now, how to do it. Well, it's simple, you can see the memory and CPU usage of your App Service in the Overview blade of your App Service in the portal. Note that you would need at least two memory dumps to confirm a memory leak. Likewise, CLR Profiler can be used to find out what section of your code is doing the most work at the time of profiling, so it's important to profile when the time issue is occurring in your App Service. After selecting the options, click Run.

Azure will capture the data and then perform the analysis, and share the analysis report which you download and act upon, as shown in the following screenshot:

The CLR Profiler .diagsession file can be downloaded by clicking on the .diagsession file shown in the image under the Collection Status column, and opened in Visual Studio. It will give you the hot path as well as the code block and methods doing the most work during the profiling session. The Memory Dump can also be downloaded and you can do a memory dump analysis locally using Windbg or DebugDiag, as needed. Azure provides a DebugDiag analysis report which can be directly downloaded.

• Azure Service Profiler: Use Azure Service Profiler to identify high CPU issues. This has great support for ASP.NET Core 2.0. The setup details and value it provides can be seen at https://www.azureserviceprofiler.com/. On installing this Profiler for your web app, it will run as a web job and diagnose the issue by identifying the hot paths. It also summarizes performance data to find long-tail performance problems.
• Profiling the app for high CPU: With the detailed metrics on CPU and memory provided by Azure, we can easily identify whether the App Service is using high CPU. If it is, how do we figure out what is causing the app to use high CPU? Yes, profiling. Profiling is easy to do in Visual Studio and even in Azure. Even though DaaS does the profiling, I always see w3wp.exe getting profiled and not the actual application .exe that we have built. To profile our application code, we can do the following simple steps:
  1. In the Azure portal, select the App Service that you wish to profile (search for the App Service and click it).
  2. In the left panel of the App Service, click on Advanced Tools. This will open the Advanced Tools blade. Click on the Go button in this blade. This will take you to the Kudu site of your App Service. There is a shortcut to reach here. If your App Service URL is http://myappservice.azurewebsites.net, then the corresponding Kudu site would be http://myappservice.scm.azurewebsites.net. Notice scm between myappservice and azurewebsites.net. You must have required access to the Kudu site, so not everyone can go to the Kudu site of any website:
  
  3. In the top bar, select Process explorer. This will open the Process Explorer as shown here:
  
  4. Click on the Start Profiling button of your application .exe, when you observe high CPU in the app. It will take a while to start profiling. Once the profiling is done, click on Stop Profiling. This will start generating the diagnostics and generate the .diagsession file, which you will be prompted to download.
  5. Upon downloading the file, open it with Visual Studio. It will show the CPU graph. There will be a button called Create detailed report. Click on it and it will open a nice-looking report with hot paths, a summary, and will lead you to the code causing the high CPU, as shown here:
  
• Support: Now that we know the Kudu site, another diagnostic tool that may be useful is Azure App Service Support, which can be browsed by appending /support in the Kudu site URL. For the preceding example, the support site would be http://myappservice.scm.azurewebsites.net/support. As of writing this chapter, it is in a preview state. We can Observe, Analyze, and Mitigate the issues from here, as shown in the following screenshot. The Observe section can be used to view stats such as requests/second and errors/sec. The Analyze section can be used to view FREB (Failed Request Error Buffering) Logs, Event Viewer logs, and running Diagnostics to figure out CPU and memory issues. The Mitigate section has a switch to autoheal the app. Most memory and CPU issues are resolved upon restart and that is where the autoheal feature comes into the picture. If you have a scenario where you need to recycle the application automatically, after it has served, say, X number of requests in Y amount of time, you can consider autoheal as an option—X and Y can be configured by means of a rule:

• New support request: If none of these options seem to have helped you identify the issue, which shouldn't happen often if done well, you can leverage the expertise of Azure support to help you with an issue, by creating a New support request in the left panel of your App Service, as shown here:

Next, let's have a quick look at a new experimental project of the ASP.NET team called Blazor.