Azure Monitor vs Application Insights vs Log Analytics

The three names show up in the same portal blades, the same billing lines and the same Stack Overflow answers, so it’s natural to compare them as products. They’re better understood as a stack.

Three layers, one data store

Azure Monitor has two data platforms. Logs go to Log Analytics workspaces and are queried with KQL; Prometheus and OpenTelemetry metrics go to Azure Monitor workspaces and are queried with PromQL. Despite the similar names, Microsoft stresses they are separate resource types with different stores and languages.

Log Analytics means two things. The workspace is a data store of tables, each with its own retention and plan. The Log Analytics tool is the query editor in the portal, with a simple point-and-click mode and a KQL mode. When people say “query it in Log Analytics” they usually mean the tool pointed at a workspace.

Application Insights is a resource you create per application (or per environment), with a connection string your app sends telemetry to. It stores that telemetry in the workspace it’s linked to and builds the APM experiences on top: Application Map, transaction search, Failures and Performance, Live Metrics, availability tests, usage analytics.

Same data, two schemas

The table and column names differ depending on where you query from. Microsoft keeps both for backward compatibility with dashboards and queries written before the workspace names existed.

Failed requests per service in the last hour, from the Application Insights Logs blade:

requests
| where timestamp > ago(1h)
| summarize failed = sumif(itemCount, tostring(success) =~ "false") by cloud_RoleName

The same question in the workspace:

AppRequests
| where TimeGenerated > ago(1h)
| summarize failed = sumif(ItemCount, Success == false) by AppRoleName

Both count with the item count, because sampling is on by default; see the sampling guide. The queries in the KQL library use the classic names and note the workspace equivalents in their pitfalls.

Classic SDK 2.x and classic resources

The SDK version doesn’t decide the schema. A request recorded by the classic .NET SDK 2.x (deprecated, retiring March 31, 2027), by SDK 3.x or by an OpenTelemetry distro lands in the same AppRequests table.

What used to decide it was the resource. Classic Application Insights resources kept telemetry in their own store, outside any workspace, so they only had the classic schema and were queried across apps with the app() function. Telemetry ingestion into classic resources stopped on June 15, 2025, and migrated resources write to a workspace. Two migration details still trip people up:

• No old data was copied. Data from before the migration stays in the classic store under its old retention. Querying the workspace directly shows only data ingested after the migration; the Application Insights Logs blade shows both.
• Renaming a migrated resource makes its Logs blade lose the pre-rename telemetry; the workspace’s Logs blade still shows all of it.

Microsoft promises full backward compatibility for classic-schema queries, workbooks and log-based alerts within the Application Insights experience.

Today: SDK 3.x and the Microsoft OpenTelemetry Distro

Apps on the Microsoft OpenTelemetry Distro or SDK 3.x send to the same ingestion endpoint and land in the same App* tables, so everything above holds. The OpenTelemetry vocabulary maps cleanly: a server span is a request, client and internal spans are dependencies, a log record is a row in traces, and the trace ID is the operation ID.

One newer path is different. Telemetry sent through native OTLP ingestion (an OpenTelemetry Collector sending to a data collection endpoint) is stored in OTelSpans and OTelLogs rather than the App* tables, and its ClientIP is always 0.0.0.0. If you mix both paths, your queries need to read both sets of tables.

Which to query, when

One workspace or several?

Because the workspace is the unit of storage and billing, the layout decision is really a workspace decision. Pointing several Application Insights resources at one workspace lets a single query cover every service and the infrastructure under it, without workspace() unions, and lets one commitment tier cover the combined volume. Separate workspaces per environment or per team give each its own bill, its own retention settings and a clean boundary for who can read what.

A common middle ground is one workspace per environment: production apps share one, test apps another. That keeps a noisy load test from ever touching the production bill or alerts, while cross-service queries in production stay simple.

Who bills what

Because workspace-based Application Insights stores data in a Log Analytics workspace, the workspace bills ingestion and retention, and every Log Analytics pricing option, commitment tiers included, applies. Application Insights itself bills a few features of its own, such as standard availability test runs and alerting on custom metric dimensions. Live Metrics has no data charge. The numbers are in Application Insights pricing.

Troubleshooting

For a plain-language tour of the feature itself, start with What is Application Insights?