Instrument solutions to support monitoring and logging is part of Monitor, troubleshoot, and optimize Azure solutions topics. The total weight of this in the exam will be 10-15%. This training post is designed to help and provide readers with a better understanding of the topic mentioned.
Disclaimer: This is not a training article to help complete the Microsoft Azure AZ-204, but it provides a good insight into the areas within these topics. Labs and hands-on work are essential to passing most Microsoft Azure exams.
Instrument solutions to support monitoring and logging: configure instrumentation in an app or service by using Application Insights
Instrument solutions to support monitoring and logging
Application Insights for webpages
Application Insights for webpages – code
Insert the script just before the </head> tag of every page that you want to track. If your website has a master page, you can put the script there. For example, in an ASP.NET MVC project, you’d put it in View\Shared\_Layout.cshtml.
The script contains the instrumentation key that directs the data to your Application Insights resource.
Instrument solutions to support monitoring and logging: analyze log data and troubleshoot solutions by using Azure Monitor
Instrument solutions to support monitoring and logging
What data does Azure Monitor collect?
Azure Monitor can collect data from:
Azure Monitor can collect data from a variety of sources. You can think of monitoring data for your applications in tiers ranging from your application, any operating system and services it relies on, down to the platform itself.
Azure Monitor collects data from each of the following tiers:
Application monitoring data
Data about the performance and functionality of the code you have written, regardless of its platform.
Guest OS monitoring data
Data about the operating system on which your application is running. This could be running in Azure, another cloud, or on-premises.
Azure resource monitoring data
Data about the operation of an Azure resource.
Azure subscription monitoring data
Data about the operation and management of an Azure subscription, as well as data about the health and operation of Azure itself.
Azure tenant monitoring data
Data about the operation of tenant-level Azure services, such as Azure Active Directory.
Azure Monitor sources
All data collected by Azure Monitor fits into one of two fundamental types, metrics and logs.
Metrics are numerical values that describe some aspect of a system at a particular point in time. They are lightweight and capable of supporting near real-time scenarios.
Logs contain different kinds of data organized into records with different sets of properties for each type. Telemetry such as events and traces are stored as logs in addition to performance data so that it can all be combined for analysis.
Application Insights overview
Application Insights is an extensible application performance management (APM) service for web developers on multiple platforms. Use it to monitor your live web application. It will automatically detect performance anomalies. It includes powerful analytics tools to help you diagnose issues and understand what users actually do with your app.
Application Insights is aimed at the development team, to help you understand how your app is performing and how it’s being used. some examples of what it monitors:
Request rates, response times, and failure rates
Find out which pages are most popular, at what times of day, and where your users are. Observe which pages perform best. If your response times and failure rates go high when there are more requests, you might have a resourcing problem.
Dependency rates, response times, and failure rates
Find out whether external services are slowing you down.
Analyze the aggregated statistics, or pick specific instances and drill into the stack trace and related requests. Both server and browser exceptions are reported.
Page views and load performance
Reported by your users’ browsers.
Application Map helps you spot performance bottlenecks or failure hotspots across all components of your distributed application. Each node on the map represents an application component or its dependencies; and has health KPI and alerts status. You can select through from any component to more detailed diagnostics, such as Application Insights events. If your app uses Azure services, you can also select through to Azure diagnostics, such as SQL Database Advisor recommendations.
Instrument solutions to support monitoring and logging: implement Application Insights Web Test and Alerts
Instrument solutions to support monitoring and logging: implement code that handles transient faults
Instrument solutions to support monitoring and logging:
An application that communicates with elements running in the cloud has to be sensitive to the transient faults that can occur in this environment. Faults include the momentary loss of network connectivity to components and services, the temporary unavailability of a service, or timeouts that occur when a service is busy.
These faults are typically self-correcting, and if the action that triggered a fault is repeated after a suitable delay, it’s likely to be successful. For example, a database service that’s processing a large number of concurrent requests can implement a throttling strategy that temporarily rejects any further requests until its workload has eased. An application trying to access the database might fail to connect, but if it tries again after a delay, it might succeed.
Handling transient errors
If an application detects a failure when it tries to send a request to a remote service, it can handle the failure by using the following strategies:
If the fault indicates that the failure isn’t transient or is unlikely to be successful if repeated, the application should cancel the operation and report an exception. For example, an authentication failure caused by providing invalid credentials is not likely to succeed no matter how many times it’s attempted.
If the specific fault reported is unusual or rare, it might have been caused by unusual circumstances, such as a network packet becoming corrupted while it was being transmitted. In this case, the application could retry the failing request again immediately, because the same failure is unlikely to be repeated and the request will probably be successful.
Retry after a delay
If the fault is caused by one of the more commonplace connectivity or busy failures, the network or service might need a short period of time while the connectivity issues are corrected or the backlog of work is cleared. The application should wait for a suitable amount of time before retrying the request.
Retrying after a transient error
The application invokes an operation on a hosted service. The request fails, and the service host responds with HTTP response code 500 (internal server error).
The application waits for a short interval and tries again. The request still fails with HTTP response code 500.
The application waits for a longer interval and tries again. The request succeeds with HTTP response code 200 (OK).
Handling transient errors in code
This example in C# illustrates an implementation of this pattern. The OperationWithBasicRetryAsync method, shown below, invokes an external service asynchronously through the TransientOperationAsync method. The details of the TransientOperationAsync method will be specific to the service and are omitted from the sample code.
The statement that invokes this method is contained in a try/catch block wrapped in a for loop. The for loop exits if the call to the TransientOperationAsync method succeeds without throwing an exception. If the TransientOperationAsync method fails, the catch block examines the reason for the failure. If it’s believed to be a transient error, the code waits for a short delay before retrying the operation.
The for loop also tracks the number of times that the operation has been attempted, and if the code fails three times, the exception is assumed to be more long lasting. If the exception isn’t transient or it’s long lasting, the catch handler will throw an exception. This exception exists in the for loop and should be caught by the code that invokes the OperationWithBasicRetryAsync method.
More topics on Monitor, troubleshoot, and optimize Azure solutions: