Benefits of Azure Application Insights

When an application fails in production, the first problem is often not fixing the bug. It is understanding what happened.

Azure Application Insights helps with that investigation. It collects telemetry from an application and brings requests, dependencies, exceptions, logs, and performance information into Azure Monitor. Instead of checking separate files and trying to reconstruct a failure manually, it provides one place to follow the operation from the incoming request to the calls made by the application.

This is useful even for a small .NET application. The initial setup is simple, and the collected data can answer practical questions such as:

Which endpoints are failing?
Which requests are slow?
Is the database or an external API causing the delay?
What exception happened during a request?
Did the problem affect one operation or many users?

Application Insights does not solve these problems automatically. Its main benefit is replacing part of the guesswork with evidence.

What the .NET integration collects

Microsoft recommends the Azure Monitor OpenTelemetry distribution for new ASP.NET Core applications. OpenTelemetry works with three main signals: traces, metrics, and logs.

With the standard ASP.NET Core setup, Application Insights can receive:

incoming HTTP requests, including duration and status;
outgoing HttpClient calls;
supported SQL and Azure SDK dependency calls;
unhandled exceptions and stack traces;
logs written through ILogger;
metrics and correlation data connecting one operation to its related telemetry.

Correlation is one of the most useful parts. A failed request can be connected to its exception and to the dependency call that failed during the same operation.

For application logs, the most relevant production levels are usually:

Information for selected application events;
Warning when something unexpected happens but the operation can continue;
Error when an operation fails;
Critical when the application or an essential feature cannot continue safely.

Debug and Trace are helpful during development, but sending large amounts of them in production can add noise and increase telemetry volume.

Structured logging also makes the data easier to search:

logger.LogWarning(
    "Order {OrderId} could not be sent to provider {Provider}",
    orderId,
    providerName);

Here, OrderId and Provider become searchable properties instead of being hidden inside one long message.

ASP.NET Core still controls which log levels are exported. A simple production configuration can keep application information while reducing routine framework noise:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  }
}

This is only a starting point. A service may need more detailed logs for one namespace and less for another. The useful approach is to keep events that support an investigation and remove repeated messages that do not change the diagnosis.

What is not collected automatically

Automatic instrumentation has limits. Application Insights cannot report information that the application never produces.

Examples include:

an exception that is caught and then ignored without being logged;
a business event that has no log, trace, or custom telemetry;
work performed by a library with no supported instrumentation;
request and response bodies;
failures that happen before traffic reaches the application;
browser page views and JavaScript errors when the browser SDK is not installed.

Sensitive information should not be added to fill these gaps. Passwords, access tokens, connection strings, payment details, and personal data do not belong in telemetry.

Backend and browser monitoring

Backend monitoring runs inside the .NET application. It observes server requests, exceptions, application logs, database calls, and outbound HTTP operations.

Browser monitoring runs on the visitor's device through the Application Insights JavaScript SDK. It can report page views, client-side performance, sessions, and JavaScript errors.

These two views answer different questions. Backend telemetry can show that an API returned an error. Browser telemetry can show what the visitor experienced before that request was made. An API may only need backend monitoring, while a Razor Pages, Angular, or React application can use both when client-side behaviour matters.

Basic ASP.NET Core setup

Install the Azure Monitor OpenTelemetry package in the web project:

dotnet add package Azure.Monitor.OpenTelemetry.AspNetCore

Then register Azure Monitor in Program.cs:

using Azure.Monitor.OpenTelemetry.AspNetCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddOpenTelemetry()
    .UseAzureMonitor();

var app = builder.Build();
app.Run();

Application Insights uses a connection string to identify where the telemetry should be sent. In production, Microsoft recommends providing it through the environment:

APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=...;IngestionEndpoint=...

The value comes from the Application Insights resource in the Azure portal and should remain outside source control. After the application starts receiving traffic, telemetry can take a few minutes to appear.

A first KQL query

The Azure portal already includes views for failures, performance, live metrics, and application dependencies. For more specific questions, Log Analytics uses Kusto Query Language.

This query lists failed requests from the last 24 hours:

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| project TimeGenerated, Name, ResultCode, DurationMs, OperationId
| order by TimeGenerated desc

The OperationId helps connect a request with related traces, dependencies, and exceptions.

Application logs are stored in AppTraces. This query focuses on Warning, Error, and Critical entries:

AppTraces
| where TimeGenerated > ago(24h)
| where SeverityLevel >= 2
| project TimeGenerated, SeverityLevel, Message, Properties, OperationId
| order by TimeGenerated desc

A useful next step is to take the OperationId from an interesting result and search for other telemetry from the same operation. That is where correlation becomes more valuable than reading isolated log messages.

Cost and telemetry volume

Application Insights is not simply a fixed-cost feature. Azure Monitor charges mainly according to the amount of telemetry ingested and how long it is retained.

Verbose logs, repeated exceptions, high traffic, and unnecessary custom properties can increase that volume. Sampling and filtering can reduce it, while cost alerts and daily caps can help detect unexpected ingestion. These controls need balance: removing too much telemetry can also remove the information required to investigate a failure.

A sensible starting point is automatic backend telemetry, structured logs at useful levels, and a small number of queries for common problems. More telemetry can be added when there is a clear question it needs to answer.