2.1.4.1. Design for Azure Monitor
2.1.4.1. Design for Azure Monitor
💡 First Principle: A unified observability platform that centralizes telemetry data (metrics and logs) from all sources is essential for achieving end-to-end visibility and enabling proactive operational management.
The telemetry pipeline, from source to action:
Two stores, and the distinction is examined constantly. Metrics are numeric, lightweight and retained briefly — good for fast alerting on a threshold. Logs are structured records in a Log Analytics workspace, queried with KQL, and are where anything requiring correlation or long retention belongs. Application Insights is the application-facing front end for both, and it writes into a workspace.
Scenario: You are designing the monitoring solution for a new enterprise application. This involves collecting performance data from Virtual Machines and Azure SQL Databases, aggregating all application logs into a central repository, and setting up alerts for critical events like high CPU usage or application errors.
Azure Monitor is a unified monitoring solution that helps you understand how your applications and other resources are performing and proactively identifies problems.
Azure Monitor Architecture:
- Data Sources: Telemetry originates from Azure resources (VMs, databases, containers), applications (via SDKs), operating systems, and custom sources.
- Data Platform: Ingests and stores metrics (numerical, near real-time) and logs (structured/unstructured, detailed events). Metrics are optimized for fast querying; logs are stored in Log Analytics for deep analysis with KQL.
- Insights: Pre-built solutions like VM Insights and Container Insights deliver tailored monitoring and recommendations for specific workloads.
- Visualization: Data is visualized through Azure dashboards, Workbooks (customizable reports), and Power BI integration.
- Respond: Automated responses are enabled via alerts, autoscale, and integrations with ITSM tools or webhooks.
Designing Data Collection Strategies:
- Metrics: Capture real-time performance and health (e.g., CPU, memory). Ideal for dashboards and threshold-based alerts.
- Logs: Store detailed diagnostics, security, and audit data for root cause analysis and compliance.
- Diagnostic Settings: Configure resources to send logs/metrics to Log Analytics (for querying/alerting), Storage Accounts (for retention), or Event Hubs (for streaming).
- Workspace design: Point every tier's diagnostic settings at one Log Analytics workspace unless sovereignty, retention or access boundaries force a split — a question that spans tiers is then one KQL query over one data set, with no cross-workspace scoping to maintain. Application Insights adds distributed tracing: instrumented with its SDK or OpenTelemetry, each request carries an operation ID through every dependency call, so one slow transaction can be followed end to end across services — which per-service metrics cannot show, and hand-joined request IDs reproduce only if every service emits and logs them consistently.
- Retention tiers: each workspace table has analytics (interactive) retention — queryable with KQL, up to 2 years — and cheaper long-term retention (formerly archive) up to 12 years, reached through a search job or restore. Keep the recent window interactive and the audit tail in long-term retention; a storage account holds logs cheaply but offers no KQL over them.
- Automated response: a threshold that must notify someone is an alert rule plus an action group; adding capacity when a metric crosses a threshold is native autoscale on the scale set or App Service plan, not a scheduled or email-triggered runbook. Host measurements such as VM CPU are platform metrics; Application Insights instruments application code, not the host.
⚠️ Common Pitfall: Relying only on metrics. Metrics tell you that something is wrong (e.g., high CPU), but logs tell you why it's wrong (e.g., a specific process is consuming all the CPU). A complete solution requires both.
Neighbouring services that are not the monitoring platform (frequent distractors):
| Service | What it actually reports |
|---|---|
| Azure Service Health | Azure platform incidents, planned maintenance and advisories, plus (through Resource Health) whether an individual resource is available — silent when the platform is healthy and your own application is slow |
| Network Watcher | Network-layer diagnostics: connection troubleshoot, flow logs, Connection Monitor, packet capture — no application telemetry or application-log aggregation |
| Azure Advisor | Periodic best-practice recommendations (cost, reliability, security, performance, operational excellence) — not a real-time telemetry or incident-alerting pipeline |
| Microsoft Sentinel | SIEM/SOAR for security detection over a workspace — not the general destination for performance troubleshooting |
| Dashboards / Workbooks | Visualise data for whoever is looking — they never notify; alerting is alert rules + action groups |
Key Trade-Offs:
- Metrics vs. Logs: Metrics are lightweight, fast, and good for alerting on known conditions. Logs are more verbose, providing rich context for deep troubleshooting, but are more expensive to ingest and query.
Practical Implementation: KQL Query in Log Analytics
// This KQL query finds all performance records for a specific computer
// where the CPU utilization was over 90% in the last hour.
Perf
| where Computer == "MyWebAppVM1"
| where CounterName == "% Processor Time" and CounterValue > 90
| where TimeGenerated > ago(1h)
Reflection Question: How does designing for Azure Monitor, integrating its data collection strategies (metrics, logs via diagnostic settings) with alerting and visualization capabilities, fundamentally ensure end-to-end visibility and proactive operational management for your Azure applications and infrastructure?
