Instrument solutions to support monitoring and logging

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

Use Application Insights for webpages to find out about the performance and usage of your webpage or app. If you add Application Insights to your page script, you get timings of page loads and AJAX calls, counts and details of browser exceptions and AJAX failures, and user and session counts. All these can be segmented by page, client OS and browser version, geo-location, and other dimensions. You can set alerts on failure counts or slow page loading. And by inserting trace calls in your JavaScript code, you can track how the different features of your webpage application are used.

Application Insights for webpages – code

Application Insights can be used with any webpages—you just add a short piece of JavaScript. If your web service is Java or Microsoft ASP.NET, you can integrate telemetry from your server and clients.

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.

Application Insights for console applications

Install latest Microsoft.ApplicationInsights NuGet package žInstall latest Microsoft.ApplicationInsights.DependencyCollector NuGet package ž

Set the instrumentation key

  • By using the static TelemetryConfiguration.Active.InstrumentationKey property
  • By using the APPINSIGHTS_INSTRUMENTATIONKEY environment variables
  • By using the ApplicationInsights.config file

Application Insights platforms

Official support – languages

  • .NET (C# & Microsoft Visual Basic)
  • Java
  • JavaScript
  • Node.js

Unofficial support – languages

  • F#
  • PHP
  • Python
  • Ruby

Official support –platforms/frameworks

  • ASP.NET (including ASP.NET)
  • Android
  • Angular Azure (Azure App Service, Azure Cloud Services, Azure Functions)
  • Docker
  • Glimpse
  • iOS
  • Java 2 Platform Enterprise Edition (J2EE)
  • OS X Spring Universal Windows Platform (UWP)
  • Windows Communication Foundation (WCF)
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.

Data sources

Monitoring data in Azure comes from a variety of sources that can be organized into tiers, the highest tiers being your application and any operating systems and the lower tiers being components of Azure platform. 

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.

Monitored metrics

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

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

Find Content

Instrument solutions to support monitoring and logging:
implement code that handles transient faults

Instrument solutions to support monitoring and logging:

Transient errors

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

  1. 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).
  2. The application waits for a short interval and tries again. The request still fails with HTTP response code 500.
  3. The application waits for a longer interval and tries again. The request succeeds with HTTP response code 200 (OK).
The following diagram illustrates invoking an operation in a hosted service using the retry pattern described in this slide. If the request is unsuccessful after a predefined number of attempts, the application should treat the fault as an exception and handle it accordingly.

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:

Integrate caching and content delivery within solutions

Microsoft Azure AZ-204 exam topics:

If you have covered the current topics in Monitor, troubleshoot, and optimize Azure solutions then you can have a look at the other topic areas:

If you have covered the current topics in Connect to and consume Azure services and third-party services then you can have a look at the other topic areas:

View full documentation Microsoft Azure: AZ-204 exam content from Microsoft

Leave a Reply