Azure Monitor
Azure Monitor is the umbrella observability platform for everything in Azure — metrics, logs, alerts, and dashboards across every resource. Application Insights and Log Analytics are not separate products but parts of it: Monitor is the platform, and they are the application-telemetry and log-query components inside it.
Treating them as separate tools is the most common conceptual error. Once you see Monitor as one platform with two data types — numeric metrics and queryable logs — feeding alerts, dashboards, and downstream tools, the rest of this chapter falls into place.
Metrics and Logs
Monitor handles two fundamentally different data types. Metrics are numeric time series — CPU percentage, request count — stored in a fast, cheap time-series database, ideal for near-real-time alerting and charts. Logs are structured records — events, traces, telemetry — stored in a Log Analytics workspace and queried with KQL for rich analysis. Use metrics for fast numeric alerting and logs for investigation and correlation.
Alerts and Action Groups
Alert rules fire on a metric threshold, a log query result, or an activity-log event, and route to an action group — a reusable set of notifications and actions (email, SMS, webhook, Logic App, auto-scale, ticket). Separating the condition (the alert rule) from the response (the action group) lets many alerts share one escalation path and keeps notification logic in one place.
Dashboards and Workbooks
Dashboards pin metrics and query results for at-a-glance views; workbooks combine text, parameters, metrics, and KQL into interactive, shareable reports for investigation and reporting. Workbooks are the richer tool for analysis, while dashboards suit always-on operational displays.
Data Sources
Monitor ingests platform metrics and resource logs from Azure services automatically, the subscription-level activity log (control-plane operations — who did what), and custom telemetry from applications and agents. Many resource logs are off until you create a diagnostic setting to route them to a workspace — a frequent gap where teams assume data is being collected that never was.
Azure Monitor — The umbrella platform — metrics, logs, alerts, dashboards across all resources. The whole observability service.
Log Analytics — The log store and KQL query engine inside Monitor. Where logs land and are queried.
Application Insights — The application performance monitoring component of Monitor — traces, dependencies, exceptions for app code.
- Treating Monitor, Log Analytics, and Application Insights as separate products rather than one platform with parts.
- Assuming resource logs are collected when no diagnostic setting routes them to a workspace — the data is simply never captured.
- Alerting on logs for conditions that metrics would catch faster and cheaper, adding query latency to time-critical alerts.
- Putting notification logic in every alert rule instead of reusing action groups for a consistent escalation path.
- Building only static dashboards when an interactive workbook would serve investigation far better.
- Ignoring the activity log, then having no record of who changed a resource during an incident.
- Think of Monitor as one platform: metrics for fast numeric alerting, logs for investigation and correlation.
- Create diagnostic settings to route resource logs to a Log Analytics workspace — collection is not automatic.
- Use metric alerts for time-critical numeric thresholds and log alerts for richer conditions.
- Define reusable action groups so many alerts share one escalation and notification path.
- Use workbooks for interactive investigation and dashboards for always-on operational views.
- Collect the activity log so control-plane changes are auditable during incidents.
Knowledge Check
How do metrics and logs differ in Azure Monitor?
- Metrics are numeric time series for fast alerting; logs are structured records queried with KQL for investigation
- Metrics are stored in the Log Analytics workspace, while logs are streamed live to the portal and never persisted to any store
- Logs are purely numeric counters, while metrics are free-form text strings
- They are identical data types that can be used interchangeably for any purpose
A team expects resource logs but the workspace is empty. What is the most likely cause?
- No diagnostic setting was created to route those resource logs to the workspace
- A Log Analytics workspace cannot serve as a valid destination for resource logs at all
- The metrics database silently overwrote the incoming resource log entries
- Resource logs require Application Insights to be enabled on the resource first
What is the purpose of an action group?
- A reusable set of notifications and actions that many alert rules can share
- A saved KQL query that defines the firing condition and threshold of an alert rule
- A reusable dashboard layout template for visualizing metrics
- A retention policy that controls how long logs are kept
You got correct