AZ-204 Microsoft Azure Developer Associate – Monitor, troubleshoot, and optimize solutions part 3
- AZ-203/ 204 – What is Application Insights
Hi and welcome back. So in this chapter, let’s have an introduction onto the tool known as Application Insights. So this is an application performance management service that’s available for web developers. You can use this tool to monitor your applications and it can actually help developers detect anomalies in their application. It can also help diagnose issues and it can also also understand it can also help you understand how users use your application. So there are a lot of use cases for using Application Insights as a performance management service. It can also help you improve the performance and usability of your application. So how does it generally work? Well, first you install a small instrumentation package. So if you’re using net, you would install the application insights. SDK. So you’d install this package within your application. You can then see the stats of your application locally in Visual Studio as you run your application.
Or you can also use the Application Insights in Azure to monitor your application. So what are the different aspects that get monitored by Application Insights? Well, first you have request rates, the response time and the failure rate. So this is done at a page level for your application. It can also record the exceptions. It can also record the page views and the load performance has reported from the user’s browser. It also gives you the count of users and sessions. It also gives you performance counters if your application is being hosted on an underlying Windows or Linux machine. You can also have diagnostic trace logs from your application sent onto the Application Insights resource. Developers can also write their own custom events or metrics. And that can also be recorded onto Application Insights.
Now, when it comes to the features of Application Insights, understanding how users use your application, what are the important aspects from an exam perspective? So you have a feature known as Funnels. You can create a funnel from one stage of your application on to another stage. And then you can see how users flow from one stage to another in that application. So you can see how users are progressing to the stages of the funnel. You also have user flows. This helps you visualize how users navigate between pages in your site. This can help you answer questions such as does the user navigate away from a page on your site? What users click on a page on your site? What are the places where users churn most on the site? And are there places where users repeat the same action over and over again? Please note this is all important from an exam perspective.
That’s why I’ve taken this directly from the Microsoft documentation and placed it over here so that you can revise this for the exam. Apart from funnels and user flows, you also have impact. This helps decide if a page is having an impact on your application. So it can help you answer the question as to whether the page loading time is impacting. How many people actually go on a page in the application. You then have retention. This helps you understand how many users return to your application. It can also help you understand if users are able to perform certain tasks in your application. Right, so this was an introduction onto application insights. Let’s go on to the labs to understand more on the server.
- AZ-203/ 204 – Lab – Getting started with Application Insights
So here we are, Nazir. Now, there are various ways to actually get started with using Application Insights. If you want, you can actually go ahead and create a resource. So you can go ahead and create a new Application Insights resource itself. But there are other ways of working with Application Insights. Now remember that your metric data, your application data can be sent from not only Azure, you could have your on premise web application that could be sending its data onto an Application Insights, onto Azure. You could also use application insights from an Azure web app. So here I have an Azure web app in place. So there is a separate setting on Application Insights. So currently Application Insights has not been turned on. So we can go ahead and turn on Application Insights. Please note that you can also enable Application Insights when you’re creating an Azure web app itself.
So here it will go ahead and create a new Application Insights resource for you. So you can give a different name. So I’m giving a name of insights. App 2020. And let’s go ahead and click on Apply. I’ll click on yes. So now it’s going ahead and applying the changes. Now, once changes are applied, if I go to all resources now, you can see that there’s an Application Insights resource in place as well. Let me just open all resources in a new tab. I just want to go on to our web application, right, so now we have App Insights in place. Now currently we don’t have any application running as part of the web app. It’s only the demo app which is in place. If I just copy this onto a new tab. So this is the demo app which comes as part of a Zero web apps.
So here I just got the template for a simple ASP. Net application. It’s in 4. 7. So let me go ahead and just publish this application as it is onto our web app. So let me go ahead and click on Publish. I’ll select an existing app service. So I’ll choose my web app, click on OK and let’s go ahead and publish this web application onto Zero. Now, once the app is published, if I just go ahead and refresh the page. So now we can see our ASP. Net application. If you go on to Application Insights, there’s a lot of things that are available if I go on to the Live metric stream. So over here it’s actually going to go ahead and connect to your application and it’s going to give you a live stream of different metrics for the application, such as incoming request, outgoing request, the overall health, et cetera.
If you go on to the application, you can go ahead and exercise the application. So you can go on to the different pages if you go on to the Live metric stream. So you can now see that the requests are coming in from your application. So the live metric stream that’s actually coming in from your application onto Application Insights. Now, if you have Telemetry data as well, that will be recorded over here. For now, let’s leave this hazardous. Let’s go back on to application insights. Right, so, so far in this lab, what we have seen is that how to get started with using Application Insights. Now, let’s move on to the next chapter. Let’s see how we can add the Application Insights SDK, our ASP dotted application, which is very simple. And then see how to view the Telemetry data right from Visual Studio itself and then from Application Insights in Azure.
- AZ-203/ 204 – Lab – Application Insights – Other aspects
Right, so here we are in Visual Studio. Now, if I gross rightclick on the project and I click on Add here I can see Application Insights telemetry. So let me choose that. Let me click on get started. So we’ll choose our existing Application Insights resource so we can rest our application with that resource. Let’s click on restoration. So now it’s going ahead and adding all the packages that are required for Application Insights for this particular code. So now you can start instrumenting your code and sending the data on to Application Insights. Now, once this is done, so the only thing that’s not enabled is trace collection. So let’s leave that as it is. Now let’s go ahead and run our application. So let’s exercise the application by going on to the different pages.
Now, in Visual Studio over here, you can see that there is something known as Application Insights in Visual Studio itself. So if you open this, you will now get all the requests that are being made onto your application. For each request you will get data about the request. So you will get the response code, you will get the response time. So this is all the telemetry data that’s now being recorded because you have the Application Insights SDK as part of your solution of your project. And now that’s getting registered as part of your project. So let me go ahead for your application. But let’s say now you want to go ahead and view this in a zero in Application Insights in a central location. So let’s go ahead and republish our application. So let me publish this. So now remember, it’s going to publish even the SDKs for Application Insights. So once this is done, we can go ahead. Let me refresh this page once. Done. Again, let’s go ahead and exercise our application.
Let’s go back on to application insights. Now, what’s the importance of actually instrumenting your code, the pages, the events, so that it is sent on to Application Insights is so that the usage, the features such as funnels, user flows, retention, impact, all have some sort of information about your application. Without instrumenting your code with the SDK, without the code sending that data onto Application Insights, you will not get this information. So before we actually go on to this, I want to go on to something known as the application map. So in the application map, you now get some data. So if you go on to view details so now you can see all of the different requests and the average duration for each request, right, that is from the application map. If you go on to the failures, you can see if there are any failures being recorded. So if there are any exceptions in your code, you will be able to see it over here.
If you go on to performance again, you can see the performance of all your web pages. So all of this is now coming because the Application Insights SDK is now instrumenting your application and sending it on to Application Insights if you go on to users so you can see the number of users for your application, you can see the number of sessions for your application. If you go on to Funnels, just click on Get Started. If you go on to User Flows, you can now see the flow of your application. If you click on Edit over here, you can decide what should be the initial event that triggers the user flow. So you can actually customize this graph, but in this graph you can actually see the user flow of your application if you go on to the impact, if you now go on to the funnels. So remember, funnels allows you to see the user flow for one stage of your application onto another.
So let’s say you want to see how do users flow from the home page of your application onto, let’s say, the contact page. So here it will let you know the percentage of users who have gone from your home page on to the contact page. So this is very useful if you want to see the number of users that are being converged or converted from your home page on to a particular page in your application. You can create a funnel for this if you go on to retention. So here you can see how users are being retained for your application. So here you can see over a duration of time our users coming back to your application. So this is again on the retention, how well your users are actually coming back onto your application and then you have impact. So impact, this is basically going to see that how does going on to the home page actually impact the user going on to, let’s say the contact page. So these are all different ways of seeing how users interact with your application.
Again, very important from an exam perspective, understanding funnels, user flows, retention and impact. Now apart from that, some other important aspects. So if you go on to usage and estimate cost. So here you can see the price for data ingestion and for multistep web test, you can see the monthly usage in your last 31 days and the estimated monthly cost. So it’s all based on the amount of data that Application Insights is ingesting from your different applications. The amount of data, the telemetry data that’s being sent by applications onto Application Insights. If you want, you can set a daily cap. So if you want to keep or if you want to be within a budget, you can actually create a daily volume cap for the amount of data that’s being ingested. You also have data sampling. So this is again, if you just want to have a percentage of the data that’s actually being recorded. So these are ways you can actually cut down the cost when it comes to using application insights. Right. So this marks the end of this lab.
- AZ-203/ 204 – Application Insights
Hi and welcome back. Now, from an exam perspective, let’s understand some points when it comes to Application Insights. So over here I have a web project, a simple web project wherein I’ve gone ahead and configured Application Insights telemetry. Now if I go ahead and run this program, now if I go on to Application Insights telemetry itself. So if I go on to the request so over here you can see the details of the request when you search by the fields. Over here, you can see that there is some random user ID that has been attached to this request itself. So it’s been auto generated by Application Insights has for the telemetry. So let’s say that you want to ensure that you paste your own user ID. So maybe you get this user ID from the authentication of the user itself and you want to add this on to the telemetry data.
So here you have to go ahead and actually overload the metrics which are being sent as part of telemetry from Application Insights. So let’s see how we can do that. So, in order to accomplish this in the code itself in your project, you have to go ahead and add a new class. So this class basically will inherit the interface of I telemetry initializer. So this is required. So you can actually go ahead and override this interface and then you can use the initialize method and then pass in to the context the user ID. Now, over here I’m basically hard coding the value of the user ID. But you can get this use ID to any means possible and then add it to your telemetry. And if you want, you can also add custom properties as well.
And then in the Application Insights config, you have to make sure that you add the type for the new class so that it will load when the program is loaded. So let’s go ahead and run the program now. Let’s go on to application insights. And now you can see you’re getting your User ID. So over here it’s your application that has generated the user ID. And over here you also have your event ID as well. So this is how you can actually use your own telemetry data when using Application Insights. So this marks the end of this chapter.
- AZ-203/ 204 – Transient faults
Hi and welcome back. Now in this chapter, let’s quickly talk about transient false. Now, when you’re working with resources in Aseau, you have to take in mind this concept known as transient false. This also comes into play when you’re working with resources in your onpremise infrastructure. Every sort of environment is bound to have issues. It’s not a certain fact that all underlying infrastructure, that all systems will work 100% all of the time. And that’s why we have to always prepare our applications to handle transient false. So even though the Azeo cloud environment provides services that offer high availability, durability and stability, we still need to ensure that we make our application aware of transient faults. So there could be a fault that could occur for just seconds or even milliseconds on the underlying service.
In such a time, our application should be able to understand what it should do when it encounters such an issue of such a fault. So some of the reasons for transient faults in the Azure environment are so the Azure environment is also a shared environment. So the underlying infrastructure could be used by multiple customers. Now, if the load on a particular service becomes too much, or if the throughput is reached, then the service could stop accepting connections. And again, this could be for a fraction of a second. But even during this time, since applications need to get the fastest response time, the application might be trying to connect to that service during the time the fault is actually taking place, even when throttling of request occurs from the service side, in Azure, they do this to help maintain the quality of the service.
Even during this time, your application needs to understand what it should do. Another reason is obviously the underlying hardware. So just like an on premise environment, where you have servers, where you have networks, where you have load balances, where you have routers, so by the time the request goes to the actual origin, it goes through multiple hops, hardware hops. And during this time there could be some sort of connection latency. So your application must be able to handle such transient faults. So one of the ways to counter these faults is to basically have a retry operation in your code. So your application should be able to, let’s say, retry connection, retry a request to the service. But at the same time, it must also have an appropriate strategy for the retry operation. It should not be that your application goes in a loop and goes through the same operation over and over again because some faults might take longer.
So maybe you might have an outage on the network in a zero in a particular region. Now, that could take a couple of minutes. So if the retire operation fails, so let’s say after three times, then you should either fall back onto a service, onto another region, or maybe just give an appropriate outage page to the users saying that your application will be back available after some time. Now, the net SDK for some services already has the facility in place for handling transient faults. So for example, for Cosmos DB, the document client class will automatically retry failed attempts. You can actually set the maximum wait time for each retry and the number of retries on the whole. So here just giving an example wherein you have a connection policy.
So here the document client has a connection policy and in the options you can specify what is the maximum retry attempts on Throttle request and what is the maximum retry wait for the time in seconds. Apart from that, here is a code snippet if your code is working with an Azure SQL database. Now this code is an example of an exponential backoff. So instead of retrying the operation during a specific interval of time, you basically change the time span during each retry operation. So here this code is going to retry an operation three times. Each time the duration between the retries will change based on the time span and then in the execute a sync. That is where we actually do the operation against our Azure SQL database. Writer to some quick notes on ensuring that you can handle transient faults in your application when working with Azurebased services.