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.
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 - 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
# 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-apiMetric 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
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.
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.
- 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."