How do Azure Monitor, Log Analytics, and Application Insights relate to each other?

Azure Monitor is the umbrella platform for all monitoring data in Azure, metrics, logs, and alerts across every resource. Log Analytics is the query and storage engine underneath it that holds log data in workspaces and is queried using KQL (Kusto Query Language). Application Insights is Azure Monitor's application-performance-monitoring feature specifically, which auto-instruments application code to collect request traces, dependency calls, and exceptions, and stores that data in a Log Analytics workspace like everything else. They are not three separate products so much as one platform (Azure Monitor) with a query engine (Log Analytics) and an application-specific instrumentation layer (Application Insights) on top of it.

What is the difference between a metric alert and a log alert in Azure Monitor?

A metric alert evaluates near-real-time numeric metrics (CPU percentage, request count) against a threshold, with low latency, typically triggering within a minute or so of the threshold being crossed. A log alert runs a KQL query against Log Analytics on a schedule (e.g., every 5 minutes) and alerts based on the query's results, which supports much richer conditions (joining multiple data sources, complex filtering) but has higher latency, bounded by both the query schedule and log ingestion delay. Choose metric alerts for fast-reacting, simple threshold conditions, and log alerts for anything requiring more complex logic than a single metric can express.

Why does effective incident investigation in Azure usually require writing KQL rather than relying only on dashboards?

Dashboards are built in advance for questions someone anticipated asking; they're monitoring, not investigation. A real incident usually raises a question nobody built a dashboard for ("which specific requests failed, and what did they have in common?"), and answering that requires querying the underlying log data directly. KQL is Log Analytics' query language, and being able to write ad hoc queries, joining traces, filtering by custom dimensions, correlating across data types, is what turns "I can see something is wrong" into "I know why," which is the actual goal of observability, not just monitoring.

Azure Monitor | Cloud Tech by Victor

Overview

Azure Monitor is the platform underneath all observability in Azure, every resource emits metrics and logs into it, Log Analytics is where that log data is stored and queried via KQL, and Application Insights is the application-specific layer that auto-instruments code for request traces, dependency calls, and exceptions. Dashboards and pre-built alerts cover the failure modes a team anticipated; real incident investigation almost always requires writing an ad hoc KQL query against the underlying log data, because the actual question during an incident is rarely the exact one a dashboard was built to answer. For a hands-on walkthrough of wiring alerts to action groups and processing rules end to end, see Azure Monitor Alerts, Action Groups, and Processing Rules.

Quick Reference

Component	Role
Azure Monitor	Umbrella platform for metrics, logs, and alerts
Log Analytics	Query/storage engine for log data, queried via KQL
Application Insights	Auto-instrumented application performance monitoring
Metric alert	Near-real-time threshold on a numeric metric
Log alert	Scheduled KQL query evaluated against a condition

Syntax

kql

// KQL - compute the p95 latency threshold for a specific endpoint
// over the last hour, something no pre-built dashboard covers.
requests
| where timestamp > ago(1h)
| where name == "POST /api/orders"
| summarize p95 = percentile(duration, 95)

Examples

bash

# Enable Application Insights auto-instrumentation on an App
# Service without changing application code.
az monitor app-insights component connect-webapp \
  --app my-api-insights --resource-group rg-app --web-app my-api

An action group is the actual notification target an alert fires into, email, SMS, a webhook, an Azure Function, without one, an alert rule evaluates its condition but nobody and nothing gets told:

bash

az monitor action-group create \
  --resource-group rg-app \
  --name ag-oncall \
  --short-name oncall \
  --action email oncall-primary devops@example.com \
  --action webhook incident-bot https://example.com/hooks/pagerduty

Metric alerts are fast; log alerts are flexible

Reach for a metric alert when you need a simple threshold checked quickly (CPU, request count). Reach for a log alert when the condition needs real query logic, joining data sources, filtering by custom properties, and can tolerate a few minutes of latency.

Visual Diagram

Where an incident investigation actually happens

Common Mistakes

Treating dashboards as sufficient observability and never learning KQL, which leaves real incident investigation stuck at "something is wrong" instead of "here's why."
Using a log alert where a metric alert would work, paying the extra latency of a scheduled query for a condition that's really just a simple numeric threshold.
Not enabling Application Insights on application workloads, losing request tracing and dependency-call visibility that would otherwise be nearly free to turn on.
Ingesting excessive log verbosity into Log Analytics without considering cost, ingestion and retention both scale with volume, and unfiltered debug-level logging at production scale gets expensive fast.
Setting a workspace daily cap as a routine cost control and then losing all monitoring, alerting, and dependent-service visibility for the rest of the day once it's hit. Microsoft's own guidance is explicit that the daily cap is a safeguard against unexpected spikes, not a cost-reduction tool, and that ingestion-time transformations are the correct lever for the latter. If logs seem to have stopped mid-incident, check _LogOperation | where Category =~ "Ingestion" | where Detail contains "OverQuota" before assuming the resource itself went quiet, the workspace's reset hour is fixed per workspace and isn't configurable.

Performance

Metric alerts evaluate on a near-real-time basis (roughly one-minute granularity), while log alerts are bounded by both their query schedule and log ingestion latency, metric alerts are the right tool when detection speed matters most.
Log Analytics query performance scales with the time range and data volume scanned, scoping KQL queries with a tight time filter first is the single biggest query-speed lever available.
Application Insights sampling (collecting a representative subset of telemetry rather than 100%) keeps both cost and ingestion volume bounded on high-traffic applications without losing statistically meaningful signal.

Best Practices

Learn enough KQL to write ad hoc investigative queries; it's the actual debugging tool, not a nice-to-have on top of dashboards.
I use metric alerts for fast, simple thresholds and log alerts for anything requiring genuine query logic.
Enable Application Insights on every application workload by default, the auto-instrumentation cost is low relative to the visibility gained.
Set explicit retention and sampling policies on log ingestion to control cost, rather than defaulting to "log everything, forever."
I use ingestion-time data collection rule transformations to actually reduce ingested volume, and reserve the daily cap for what it's designed for, a hard stop against a genuine unexpected spike, not routine budget management.
Give every alert rule a real action group with a verified notification path (test the webhook/email before relying on it), an alert that fires silently is functionally the same as no alert.

Azure Monitor