Secret ingredients to quality software

SSW Foursquare

Rules to Better Application Insights - 11 Rules

  1. Knowing the holistic health of your application is important once it has been deployed into production. Getting feedback on your Availability, errors, performance, and usage is an important part of DevOps.We recommend using Application Insights, as getting it set up and running is quick, simple and relatively painless.

    Application Insights will tell you if your application goes down or runs slowly under load. If there are any uncaught exceptions, you'll be able to drill into the code to pinpoint the problem. You can also find out what your users are doing with the application so that you can tune it to their needs in each development cycle.

    Google analytics
    Figure: When developing a public website, you wouldn't deploy without Google Analytics to track metrics about user activity.

    2020 03 24 15 27 26
    Figure: For similar reasons, you shouldn't deploy a web application without metric tracking on performance and exceptions

    1. You need a portal for your app
    2. You need to know spikes are dangerous
    3. You need to monitor:

      1. Errors
      2. Performance
      3. Usage

    r437355 2104314
    Figure: Spikes on an Echidna are dangerous

    sockeye daily count
    Figure: Spikes on a graph are dangerous

    To add Application Insights to your application, make sure you follow the rule Do you know how to set up Application Insights?

    Can't use Application Insights? Check out the following rule Do you use the best exception handling library ?

  2. The best approach of setting up Application Insights in SharePoint is a bit different than adding to normal web application.

    Note: To check the normal way of setting up Application Insights via Visual Studio, please read "How to set up Application Insights"

    With a web application you are developing you have full control of web.config and have access to it in your Visual Studio project, and can follow "How to set up Application Insights" to set up Application Insights. This way Visual Studio will do all the modifications for you automatically.

    But when you develop on SharePoint, you do not have a full copy of web.config in your Visual Studio project, the web.config will be initialized on the SharePoint server when a new SharePoint site is created. This means Visual Studio cannot be used to update the web.config for you. Although you can modify SharePoint web.config via coding, that involves lots of development and testing work against your SharePoint server.

    The best process to implement Applications Insights in SharePoint can be split into two parts:

    1. Implement App Insight JavaScript in master page (via Visual Studio)  or web pages individually via embedded code, there are two good articles include the detail steps:
    4. Use Application Insights Status Monitor configuration tool to add DLLs reference and update web.config (no coding work involved), there are two articles include the detail steps:

  3. The easiest way to get started with Application Insights is to follow the documentation on MSDN

    Lets take a look at the overview and our tips to help you get the most out of Application Insights.

    An overview of the setup steps Application Insights requires that you make 2 general modifications to your application:

    1. On the client side, manuallyadd a Javascript tracker to your web page header (i.e. by placing directly on each page or through a "master page" or "layout template"), this modification enables the "browser page loading time" monitor and can track client-side exceptions:
      app insights browser loading time
      Browser side stats have been enabled with the JavaScript tracker
    2. On the server side, add the Application Insights DLL references and update web.config, these modifications enable the "server response time", "server request" and "failed requests" monitors. This step can either be done within Visual Studio when right-clicking on a project in Solution Explorer, but it can also be done with the server monitoring tool on ASP.NET applications you don't have control over (e.g. SharePoint).
    3. server response requests failed requests
      Server side stats have been enabled now that it has been added to the ASP.NET pipeline

    Tip #1 – Add enhanced Exception tracking to your application The default set up and configuration of Application Insights will send generic performance stats and Exceptions. If you will be using Application Insights to look deeper into these Exceptions then it is important to make sure the full stack trace is sent when Exceptions occur. This can be added to your application by adding code for all unhandled exceptions. Follow this documentation page for more information

    **Tip #2 – Add Web tests to monitor performance metrics over time** As soon as you have configured Application Insights, you should immediately add a web test to track the general performance trends over time. More information can be found at this rule

    Tip #3 – What if you don't have the source code of your ASP.NET application

    This rule on how to add Application Insights to a SharePoint application shows that you can use the Application Insights monitor to add the .dlls and modify the web.config file of a deployed application

  4. Application Insights can provide an overwhelming amount of errors in your web application, so use just-in-time bug processing to handle them.

    The goal is to each morning check your web application's dashboard and find zero errors. However, what happens if there are multiple errors? Don't panic, follow this process to improve your application's health.

    App Insights Failures
    Figure: Every morning developers check Application Insights for errors

    Once you have found an exception you can drill down into it to discover more context around what was happening. You can find out the user's browser details, what page they tried to access, as well as the stack trace (Tip: make sure you follow the rule on How to set up Application Insights to enhance the stack trace).

    App Insights Failures drilldown
    Figure: Drilling down into an exception to discover more.

    It's easy to be overwhelmed by all these issues, so don't create a bug for each issue or even the top 5 issues. Simply create one bug for the most critical issue. Reproduce, fix and close the bug then you can move onto the next one and repeat. This is just-in-time bug processing and will move your application towards better health one step at a time.

    20 08 2014 12 04 31 PM compressor
    Figure: Bad example - creating all the bugs

    20 08 2014 12 06 16 PM compressor
    Figure: Good example - create the first bug (unfortunately bug has to be created manually)

  5. As soon as you have configured Application Insights, you should immediately add a Web Test to track general performance trends over time. You can configure test agents to access your application from different locations around the globe to give a general idea of what users will experience.

    Instructions on how to add Web Tests can be found on MSDN

    Setting up a Web Test will allow you to query and see how the performance of your application has changed over a period of time and to help you spot any anomalies. It can be useful to query over a long period of time (e.g. a year) and see if the performance has stayed the same or if there have been any regressions in responsiveness.

    App Insights Web Test
    Good Example - You can clearly see the point where we deployed a fix to production to improve the initial page load.

    You have the ability to drill down into web test results, to get an overview of the response time of the resources on a page. This can help discover if certain resources are slowing the response time.

    App Insights Web Test drilldown
    Good Example - Reviewing the Web test results, provides vital information .

  6. Do you create a Sprint Review/Retro email?

    After any Sprint Review and Retrospective, an email should be sent to all the stakeholders to update them on the outcome from the Sprint:

    Firstly, create a new email copying the information from the previous Sprint Review/Retro. As per Do you know what happens at a Sprint Retrospective meeting?, it should include the following:

    Figure: Good example - Template for Sprint Review/Retro email

  7. Are you alerted when your site goes down?

    Nothing is worse than having your site down being unaware for a long period of time.

    Application Insights can help you minimize the downtime by sending you an Email alert when your site becomes unavailable. You should create an availability test and enable the alert option as soon as your site goes live.

    error 503

    site down2

    Bad example: Site was down over the weekend unnoticed


    Good example: Availability tests are created for multiple locations

    alert 2

    Good example: Email alert is enabled to minimize the downtime

  8. Do you have a Preflight Checklist?

    Before starting any work, you should ensure developers take a look at your Application Insights data to make sure everything is performing correctly.

    Most developers check only this first item before starting their work:

    1. Check Unit Tests are Green


    Figure: Tests are green. I'm ready to start work... or am I?

    More advanced teams check their application insights data as well. This includes:

    1. Look for any new Unhandled Exceptions

    See Do you know the daily process to improve the health of your web application?

    App Insights Failures

    Figure: Unhandled Exceptions - Is there anything you don't know about here?

    1. Look for any obvious performance issues (Server then client).

    See Do you know how to find performance problems with Application Insights?

    performance 4

    Figure: Performance - The Server Responses tab shows the slowest running pages.

  9. You've set up your Application Insights as per the rule 'Do you know how to set up Application Insights.

    Your daily failed requests are down to zero & You've tightened up any major performance problems.

    Now you will discover that understanding your users' usage within your app is child's play.

    The Application Insights provides devs with two different levels of usage tracking. The first is provided out of the box, made up of the user, session, and page view data. However, it is more useful to set up custom telemetry, which enables you to track users effectively as they move through your app.

    usage 1
    Figure: The most frequent event is someone filling out their timesheet

    It is very straightforward to add these to an application by adding a few lines of code to the hot points of your app. Follow Application Insights API for custom events and metrics to learn more.

    Feel constricted by the Application Insights custom events blade? Then you can export your data and display it in PowerBI in a number of interesting ways.

    Sugarlearning PowerBi
    Figure: Power BI creates an easy to use and in-depth dashboard for viewing the health of the application

    Previously we would have had to perform a complicated set up to allow Application Insights and Power BI to communicate. Follow How to connect Application Insights to Power BI via Azure Stream Analytic to learn more. Now it is as easy as adding the Application Insights content pack.

    Figure: Content packs make it simple to interact and pull data from third-party services

  10. Once you have set up your Application Insights as per the rule 'Do you know how to set up Application Insights' and you have your daily failed requests down to zero, you can start looking for performance problems. You will discover that uncovering your performance related problems are relatively straightforward.

    The main focus of the first blade is the 'Overview timeline' chart, which gives you a birds eye view of the health of your application.

    performance 1
    Figure: There are 3 spikes to investigate (one on each graph), but which is the most important? Hint: look at the scales!

    Developers can see the following insights:

    • Number of requests to the server and how many have failed (First blue graph)
    • The breakdown of your page load times (Green Graph)
    • How the application is scaling under different load types over a given period
    • When your key usage peaks occur

    Always investigate the spikes first, notice how the two blue ones line up? That should be investigated, however, notice that the green peak is actually at 4 hours. This is definitely the first thing we'll look at.

    performance 2
    Figure: The 'Average of Browser page load time by URL base' graph will highlight the slowest page.

    As we can see that a single request took four hours in the 'Average of Browser page load time by URL base' graph, it is important to examine this request.

    It would be nice to see the prior week for comparison, however, we're unable to in this section.

    performance 3
    Figure: In this case, the user agent string gives away the cause, Baidu (a Chinese search engine) got stuck and failed to index the page.

    At this point, we'll create a PBI to investigate the problem and fix it.

    (Suggestion to Microsoft, please allow annotating the graph to say we've investigated the spike)

    The other spike which requires investigation is in the server response times. To investigate it, click on the blue spike. This will open the Server response blade that allows you to compare the current server performance metrics to the previous weeks.

    performance 4
    Figure: In this case, the most important detail to action is the Get Healthcheck issue. Now you should be able to optimise the slowest pages

    In this view, we find performance related issues when the usage graph shows similarities to the previous week but the response times are higher. When this occurs, click and drag on the timeline to select the spike and then click the magnifying glass to ‘zoom in’. This will reload the ‘Average of Server response time by Operation name’ graph with only data for the selected period.

    Looking beyond the Average Response Times

    High average response times are easy to find and indicate an endpoint that is usually slow - so this is a good metric to start with. But sometimes a low average value can contain many successful fast requests hiding a few much slower requests.

    Application insights plots out the distribution of response time values allowing potential issues to be spotted.

    distribution **Figure: this distribution graph shows that under an average value of 54.9ms, 99% of requests were under 23ms but there were a few requests taking up to 32 seconds! **

  11. Visual Studio 2015/2017 allows you to view your Application Insights data using CodeLens.

    use codelens 1
    Figure: See live data from production servers using CodeLens

    use codelens 2
    Figure: Drill into request details right inside Visual Studio

We open source. Powered by GitHub