Rules to Better Application Insights - 14 Rules

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.

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

The easiest way to get started with Application Insights is to follow the documentation on Microsoft Learn.

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

Application Insights provide crucial insights into the health and performance of the application. Failed Requests allow the DevOps specialists to identify the specific errors and exceptions occurring in the application. However, keeping Failed Requests clean is crucial to troubleshoot and pinpoint the root causes of the problems efficiently. A cluttered failed requests list filled with irrelevant entries can make it difficult to identify the critical issues that require immediate attention.

Azure Application Insights is your app's friendly doctor, keeping an eye on it to stay healthy and running smoothly. It uses an `Instrumentation Key` (IK) to allow your app to send telemetry data to its resource.

While this IK isn't a secret and is often included in client-side code, if it IK falls into the wrong hands, they could spam your telemetry or incur extra costs on ApplicationInsights.

<endIntro />

## Instrumentation Keys do not provide read access

The IK **does not** grant users access to **read** your data. To read telemetry data, an application or user must authenticate to Application Insights using **Microsoft Entra ID** (formerly Azure AD).

For client-side telemetry, such as Static Web Apps or Single Page Applications, the key is visible in the browser via DevTools. However, Application Insights telemetry is sent over **HTTPS**.

## Use RBAC for stronger authentication

To prevent unintended access, **local authentication** using Instrumentation Keys or API Keys can be disabled for data ingestion.

Once disabled, **Role-Based Access Control (RBAC)** can be used to define exactly which applications and users are allowed to send telemetry, making unauthorized data injection harder.

## Improve monitoring and auditing

RBAC also improves monitoring and auditing because access and actions can be associated with authenticated identities.

Disabling local authentication and using **Entra ID with RBAC** therefore provides stronger control over who can submit telemetry to Application Insights.

<imageEmbed alt="Application Insights Properties page with Local Authentication set to Disabled" size="large" showBorder={true} figurePrefix="good" figure="Disable local authentication to enforce Entra ID authentication for telemetry ingestion" src="/uploads/rules/appinsights-authentication/appinsights-disable-local-auth.png" />

## Benefits and Limitations

| ✅ Pros | ❌ Cons |
| :-- | :-- |
| No spam telemetry | Does not work for Client-Side applications |
| Perfect for Server-side applications | 2 Application Insights instances to collect Client and Server-side telemetry |
| Accurate telemetry - Exact applications, servers, services are listed | Custom Queries and Dashboards to combine Client and Server-side telemetry |

## Securing Application Insights

In short, to secure the telemetry sent from your application to Application Insights, follow these steps:

1. Use System-assigned or User-assigned Managed Identity with AppService
2. Disable Local Authentication to enable RBAC
3. Assign the `Monitoring Metrics Publisher` role to the AppService
4. Authenticate your application against AppInsights using a managed identity

### Sample Application

Check out the sample ASP.NET Core application and Bicep code from [William Liebenberg](https://www.ssw.com.au/people/william-liebenberg) on [GitHub](https://github.com/william-liebenberg/AppService-AppInsights-Monitoring)

### Add Managed Identity to AppService

To provision an Azure AppService with a System Assigned managed identity, add the following to your Bicep code:

```bicep
resource appService 'Microsoft.Web/sites@2022-09-01' = {
  name: appServiceName
  location: location
  identity: {
    // ⬇️ add the code below for Azure to automatically assign a managed identity to the AppService
    type: 'SystemAssigned'
  }
  // ... the rest of your app service configuration
```

**✅ Figure: Enable System Assigned managed identity**

### Enable Role Based Access Control for Application Insights using Bicep

When provisioning your Application Insights resource using Bicep, you can enable RBAC by setting `DisableLocalAuth` to `true`.

```bicep
resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: appInsightsName
  location: location
  kind: 'web'
  tags: tags
  properties: {
    Application_Type: 'web'
    Flow_Type: 'Bluefield'
    Request_Source: 'rest'
    WorkspaceResourceId: logAnalyticsWorkspace.id
    DisableLocalAuth: true // Enables RBAC
  }
}
```

**✅ Figure: Disable Local Authentication to enable Enhanced Security for Application Insights using Bicep**

Disabling the local authentication enables RBAC which means that only users and applications with the `Monitoring Metrics Publisher` role and the appropriate instrumentation key will be able to track telemetry with this instance of Application Insights.

### Assigning Monitoring Metrics Publisher Role to AppService using Bicep

To give an Azure AppService the capability of sending telemetry to an Application Insights instance with RBAC enabled, the AppService must have the `Monitoring Metrics Publisher` role assigned to it.

There are a couple of Azure quirks that make this less than trivial, but it is also not too complicated.

1. Get the Role Definition using the Azure CLI:

   ```ps1
   az role definition list --name "Monitoring Metrics Publisher" --output json --query '[].{description:description, name:name, roleName:roleName}'
   ```

   Output:

   ```json
   [
     {
       "description": "Enables publishing metrics against Azure resources",
       "name": "3913510d-42f4-4e42-8a64-420c390055eb",
       "roleName": "Monitoring Metrics Publisher"
     }
   ]
   ```

   The `name` field is a `GUID` that you use in the Bicep code to assign a role to an entity.

1. Add the following Bicep code to assign the `Monitoring Metrics Publisher` role to an Azure AppService:

```bicep
// Get the existing Monitoring Metrics Publisher role definition
resource monitoringMetricsPublisherRoleDefinition 'Microsoft.Authorization/roleDefinitions@2022-04-01' existing = {
  scope: subscription()
  name: '3913510d-42f4-4e42-8a64-420c390055eb'
}

// Assign the Monitoring Metrics Publisher role to the AppService identity
resource monitoringMetricsPublisherRoleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(appInsights.id, appService.id, monitoringMetricsPublisherRoleDefinition.id)
  scope: appInsights
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: monitoringMetricsPublisherRoleDefinition.id
    principalId: appService.identity.principalId
  }
}
```

**✅ Figure: Assigning Monitoring Metrics Publisher role to AppService Managed Identity using Bicep**

<imageEmbed alt="Application Insights Access control (IAM) page listing the AppService with the Monitoring Metrics Publisher role" size="large" showBorder={true} figurePrefix="none" figure="AppInsights shows the Monitoring Metrics Publisher role is assigned to AppService" src="/uploads/rules/appinsights-authentication/appinsights-assigned-role.png" />

### Authenticating with Application Insights

For ASP.NET Core applications running on Azure AppServices with the `Monitoring Metrics Publisher` role assigned, we can use a managed identity (System-assigned or User-assigned) to authenticate the application with a particular AppInsights instance.

We accomplish this by using one of the following [credential types](https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/identity/Azure.Identity#authenticate-azure-hosted-applications):

1. `DefaultAzureCredential` for local development
2. `ManagedIdentityCredential` for apps running in Azure with system-assigned or user-assigned managed identities
   * For system-assigned, use the default constructor without parameters.
   * For user-assigned, provide the `client ID` to the constructor.

Once the credential has been created, pass it to the Application Insights `TelemetryConfiguration`:

```cs
using AppService.AppInsights.Monitoring;
using Azure.Identity;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);

// authenticate using Default (managed identity) Credentials for AppInsights
builder.Services.Configure<TelemetryConfiguration>(config =>
{
    var credential = new ManagedIdentityCredential();
    config.SetAzureTokenCredential(credential);
});

// When using AppInsights and User Secrets for local development:
// - Strange behavior:
//    When using the parameterless version of `.AddApplicationInsightsTelemetry()`,
//    the various Initializers and TelemetryClient do not receive the
//    `ApplicationInsights:ConnectionString` specified in `secrets.json`
//
// - Fix: Pass in `builder.Configuration` to `.AddApplicationInsightsTelemetry()`
//
// - Result: the Initializers and TelemetryClients are configured properly
builder.Services.AddApplicationInsightsTelemetry(builder.Configuration);

// ---- the rest of Program.cs ----

```

**✅ Figure: Using Managed Identities when authenticating with Application Insights**

Once the application starts up, authenticates with Application Insights, then you can start observing telemetry in the Application Insights resource or Application Dashboards.

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

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.

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

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

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.

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.

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

In the Face of Armageddon - When there's a major error during deployment or a catastrophic fault happens, what is your first instinct? Is it to hit that Roll Back button?

It feels like reverting back to the previous stable version is the safest and quickest way to restore functionality.

However, rolling back can have several negative consequences, making it crucial to consider the drawbacks:

Modern cloud applications are complex distributed systems where a single user request might touch dozens of services. When something breaks, you need comprehensive observability to understand what happened. Traditional monitoring tools often lock you into a specific vendor or don't provide the full picture across your entire stack.

OpenTelemetry is the industry-standard, vendor-neutral framework for collecting telemetry data (traces, metrics, and logs) from your applications. It's backed by the Cloud Native Computing Foundation and has become the dominant observability framework in 2026.