Designing a Unified Monitoring Architecture from Azure Monitor to KQL

A practical breakdown of Azure Monitor, Log Analytics, Application Insights, Diagnostic Settings, and alert design — core AZ-305 monitoring topics built around real exam scenarios.

In the AZ-305 exam, monitoring and logging architecture is the domain that directly tests your skills as a solutions architect. Most questions focus less on memorizing service names and more on judging which configuration to choose in a given scenario. If you understand how Azure Monitor, Log Analytics, Application Insights, Diagnostic Settings, and Alert Rules connect to each other, you can answer the vast majority of questions in this domain. This post distills the key concepts and decision criteria from 25 real exam questions.

---

 

Data Flow in Azure Monitor

Azure Monitor is the unified monitoring platform that oversees your entire cloud environment. It collects data in four major categories.

Metrics are numeric time-series data — CPU utilization, memory usage, network throughput, and similar measurements. Most Azure resources emit metrics automatically, and the default retention period is 93 days.

Logs are structured event records that answer "who did what, and when." By default, logs remain inside the resource itself. To analyze them, you must route them to a Log Analytics workspace through Diagnostic Settings.

The Activity Log is a platform log that automatically records every management operation performed through Azure Resource Manager — resource deployments, deletions, configuration changes, and other control-plane events. No agent installation and no Diagnostic Settings are required; you can query it immediately, and it is retained for 90 days by default.

Diagnostic logs are operational data generated inside a resource — SQLInsights for Azure SQL Database, App Service logs, Key Vault access logs, and so on. You must configure Diagnostic Settings to specify a destination (Log Analytics, Storage Account, or Event Hub) before any of this data is collected.

Exam trap: "Query management history immediately, no agent, no extra configuration" → Activity Log. Analyzing operational logs inside a resource → Diagnostic Settings must come first.

---

 

Log Analytics Workspace Design

The Log Analytics workspace is the central log store for Azure Monitor. Exam questions frequently ask about the right number of workspaces and how to optimize costs.

Single vs. Multiple Workspaces

Network Insights, workspace-based Application Insights, Microsoft Sentinel, and VM Insights can all be consolidated into a single Log Analytics workspace. The number of services does not equal the number of workspaces. A single workspace is sufficient when the goal is centralization and cross-service correlation; consider multiple workspaces only when teams require complete isolation or data sovereignty. Because a single resource supports up to five Diagnostic Settings, two teams that each want their own independent workspace can simply create two Diagnostic Settings pointing to two different workspaces.

Data Collection Agents: AMA and DCR

The Azure Monitor Agent (AMA) replaces the legacy MMA and is used alongside a Data Collection Rule (DCR). A DCR is a policy resource that defines what to collect and where to send it.

When calculating the number of DCRs needed, the deciding factor is not the number of VMs but the difference in operating system and data source type. If you have 20 Windows VMs collecting security event logs and 15 Linux VMs collecting Syslog, you need at minimum two DCRs because the OS types differ.

A Data Collection Endpoint (DCE) is only required in network-isolated environments. If the machines can reach a public endpoint and there is no isolation requirement, the DCE count is zero. Unless the question mentions Private Link or internet blocking, assume a DCE is not needed.

Data Retention and Cost Optimization

The default retention period for a Log Analytics workspace is 30 days. The maximum interactive retention is 730 days (2 years); with the archive tier, data can be kept for up to 4,383 days (roughly 12 years). The interactive tier supports KQL queries but carries higher cost; the archive tier restricts queries but costs less.

To reduce ingestion costs, switch to a Commitment Tier pricing plan. You can save more than 30% compared to pay-as-you-go, and the change does not affect existing Alert Rules or automation runbooks. Note that the retention days setting on a Storage Account Diagnostic Settings controls the automatic Blob deletion cycle — it is separate from the Log Analytics queryable retention period.

---

 

Application Insights and Distributed Tracing

Application Insights is a dedicated application performance monitoring (APM) service. Unlike Azure Monitor, which focuses on infrastructure metrics, Application Insights specializes in transaction-level analysis and user behavior analytics.

Three Core Capabilities

Application Map visualizes the call relationships and dependencies among microservices as an interactive graph. You can instantly spot services with high error rates and identify response latency bottlenecks.

Distributed Tracing tracks the complete end-to-end timeline of a single request as it travels through multiple microservices.

User analytics delivers six types of analysis — Users, Sessions, Funnels, Retention, User Flows, and more — all within a single service.

Codeless Attach and Availability Tests

Codeless Attach enables automatic instrumentation for Azure App Service without any code or SDK changes — you activate it purely through portal settings. Whenever a question requires transaction-level response time and dependency call analysis without code changes, this feature is the answer.

Availability Tests are synthetic transaction monitoring that periodically simulates user flows without real users. Three types are supported: URL Ping tests, Standard tests, and Multi-step web tests. They run from Azure locations worldwide without requiring any agent installation. When a question asks for synthetic monitoring without additional infrastructure, choose Application Insights Availability Tests.

---

 

Alert and Automated Response Design

The alerting system is composed of three elements: an Alert Rule, an Action Group, and an Alert Processing Rule.

Alert Rules and Action Groups

Metric alerts are based on numeric thresholds — CPU utilization, HTTP 5xx error rate — and can evaluate as frequently as every minute. Log query-based alerts fire based on KQL query results. A single Action Group can be shared across multiple Alert Rules. If three events — VM restart, VM deallocation, and VM power-off — all need to notify the same recipients, the optimal design is one Action Group combined with three Activity Log Alert Rules. When recipients change, you only need to update the Action Group. Alert Processing Rules are used to suppress notifications during maintenance windows.

If logs must be collected over private paths only, with no internet traversal, use Azure Monitor Private Link Scope (AMPLS). AMPLS connects Log Analytics workspaces and Application Insights to Private Endpoints inside your VNet.

---

 

Service Comparison Table

The table below summarizes the main data types collected by the Azure Monitor platform and the characteristics of each service.

| Data Type | Primary Service | Storage | Auto-Collected | Main Use Cases | |-----------|----------------|---------|----------------|----------------| | Metrics | Azure Monitor Metrics | Metrics DB (93 days) | Mostly automatic | Real-time performance monitoring, threshold alerts | | Logs | Log Analytics workspace | Log Analytics (default 30 days) | Requires Diagnostic Settings | KQL queries, correlation analysis, long-term auditing | | Traces | Application Insights | Log Analytics-linked (default 90 days) | SDK or Codeless Attach | Distributed tracing, transaction analysis | | Activity Log | Azure Activity Log | Platform automatic (default 90 days) | Fully automatic | Management operation auditing, deployment history |

Table-level perspective: Windows VM security event logs → SecurityEvent table; Linux syslog → Syslog table; Azure management operations → AzureActivity table; resource diagnostic logs → AzureDiagnostics table. SecurityEvent and Syslog are differentiated by operating system.

---

 

Decision Criteria That Trip People Up on the Exam

Scenario 1: Auditing Management Operations

"Query resource deployment history immediately, no agent, no extra configuration" — the answer is Activity Log. It is retained automatically for 90 days. To aggregate Activity Logs from multiple subscriptions into a monthly report, route them to Log Analytics and use KQL queries.

Scenario 2: Performance Analysis Without Code Changes

"Analyze transaction-level response times and dependency calls without code changes" — Application Insights Codeless Attach is correct. Azure Monitor metric alerts are designed for aggregate-level alerting and are not well-suited for granular, per-transaction tracing.

Scenario 3: Multiple Destinations in Diagnostic Settings

"Real-time monitoring (Log Analytics) and long-term archiving (Storage Account) simultaneously" — specify both destinations within a single Diagnostic Settings configuration. If two teams each want their own independent workspace, create two separate Diagnostic Settings, each pointing to a different workspace.

Scenario 4: Dedicated AD Sync Monitoring

"Monitor Entra ID synchronization errors with dedicated tooling" — Microsoft Entra Connect Health is the answer. Azure Monitor is a general-purpose platform and does not provide the deep, AD Connect-specific visibility that Connect Health delivers. Entra Connect Health requires an Entra ID P1/P2 license and automatically detects sync errors, delays, and object mismatches after agent installation.

Scenario 5: Microservice Map and User Analytics

"Service dependency map, distributed tracing, and user analytics all in a single service" — Application Insights. Azure Monitor centers on infrastructure metrics and logs; Application Insights centers on application performance and user behavior analytics.

Back to blog list