10 Web Tests per Application Insights Resource

One of my favorite features of Azure's Application Insight resource is the Web Test.  You can use it to perform keepalive/heartbeat tests on your websites.  You can also use it to proactively be informed if your site is having problems.

Today I learned that you can only have a maximum of 10 web tests per resource.











This is still incredibly generous when you consider the
following:

• You can run any webtest from up to 16 global locations.  So each webtest can really be thought of as 16 tests.
• You can create a multi-step test using Visual Studio's Web Performance and Load Test project template.  In one of these projects, you can configure a complex series of web tests.  This only counts as 1 web test in App Insights.  But you could easily merge all of your webtests into a single project, and therefore only use 1 single webtest slot.

10 web tests per resource limitation should not be a limitation for anyone.

Don't Let Your Free Azure Website Go To Sleep... Keep It Alive With Application Insights Web Tests

Anyone can register for a Microsoft Azure account and create 10 websites for free.  However, those are hosted such that they will occasionally take 3-10 seconds to respond if they sit idle for too long.

You can keep your website alive and responsive if you have visitors more often.  Or how about creating a task that will ping your website often enough to keep it awake?  An easy and free way to achieve this is to use another Microsoft Azure service, Application Insights.

This service allows you to gather telemetry from your desktop, mobile, or web application and monitor and report off of that data.  It is real simple to setup and requires injecting settings into your config files and/or adding a few lines of code to your project.

However, you don't need to do any of that.  You can install the resource in your Azure account and just use the Web Test feature without any client/server setup.  You can have this setup in under 5 minutes inside your Azure portal.

1. Create a new resource group
2. Add application insights
3. Click on the availability tile
4. Add a web test
5. Use the URL ping test
• Add a name
• Supply the URL you want to keep alive
• Choose at least one location (I only needed one since my goal is just to use this service as a keep-alive)
• Configure the alert to email you if there are issues

Application Insights resource named Keep Azure Websites Alive

That's it!  A simple keep-alive system that is running in the cloud and doesn't cost you a penny.

Hosting multiple client side telemetry Application Insight endpoints on same domain

We have a website where one division in the company controls and builds the main content of our website, and another division deals with the online ordering cart system.  We each host our websites on separate servers, but they are served up under the same domain name and we share cookies.  The routing to the correct server is all handled up-stream by our network team, so it is seamless to the developers and our users.

The division that handles the online cart has already installed AppInsights and have been collecting client-side javascript telemetry data for a while now.  I work on the other content side of the website and we want to collect our own telemetry.

Looking at the code, the tracking logic and config is loaded and saved to a global variable: window.appInsights.  That variable is reloaded every time a page is requested and the trackPageView() is called when the page loads.

If we were to install the ApplicationInsights client code in our part of the website, which is the typical entry point into our website, then the window.appInsights object will be initialized by us and use our instrumentationKey.

To prevent our collection from replacing theirs, we updated the client code to set our own global variable.

OLD:
<script type="text/javascript">
  var appInsights = window.appInsights || function (config) { 
  ... 
  window.appInsights = appInsights; 
  appInsights.trackPageView(); 
</script>

NEW:
<script type="text/javascript">
  var appInsights = window.appInsightsSitecore || function (config) { 
  ... 
  window.appInsightsSitecore = appInsights; 
  appInsights.trackPageView(); 
</script>

Application Insights on Sitecore – Filtering the SQL telemetry

Microsoft Application Insights is a great solution to monitor telemetry data from your Sitecore installs.

The only problem is that if you enable all of the normal telemetry modules, you’ll end up flooding your data points with SQL calls.  There are thousands of SQL calls every minute in an average Sitecore database (especially in the EventQueue table).
We wanted to filter out all of those SQL calls, because we have not seen performance issues with Sitecore and SQL in our setup.


This requires at least v2.0 of the AppInsights SDK.  And then you need to create a custom filter.  I followed an example from the AppInsights documention.

namespace Sitecore.Website.AppInsights.Filters
{ 
    public class SQLFilter : ITelemetryProcessor
    {
        private ITelemetryProcessor Next { get; set; }

        // Link processors to each other in a chain.
        public SQLFilter(ITelemetryProcessor next)
        {
            this.Next = next;
        }
        public void Process(ITelemetry item)
        {
            // To filter out an item, just return 
            if (!OKtoSend(item)) { return; }

            this.Next.Process(item);
        }

        // Example: replace with your own criteria.
        private bool OKtoSend(ITelemetry item)
        {
            var dependency = item as DependencyTelemetry;
            if (dependency != null
                && dependency.DependencyKind == "SQL")
            {
                return false;
            }

            return true;
        }
    }
}

Once you have your filter class built, you need to add it to the Process 
pipeline of AppInsights in your ApplicationInsights.config file.

<TelemetryProcessors>
  <Add Type="Sitecore.Website.AppInsights.Filters.SQLFilter, Sitecore.Website" />
</TelemetryProcessors>

That’s it!  This prevents any SQL calls from flooding your AppInsights Azure
resource.

If collecting some of this SQL data is important to you, you could also look 
into the Sampling features of the SDK, which allows you to throttle the 
data that is sent.

Another option is to inspect the CommandName property and possibly just filter out the chattiness to the EventQueue table, but allow the other commands through.  I chose not to do this for now, because the goal is to fail fast in this processor, so not to cause a lot of extra logic to happen on the data collection and slow things down.  If you decide to do the extra logic in here to allow some of the SQL data through, make sure to order you conditional tests correctly, so if the DependencyTelemetry object is not a SQL kind, short-circuit and skip testing the other conditionals.