Recommend a Monitoring Solution — Lesson

This lesson focuses on the monitoring side of Azure observability: the signals, dashboards, alert rules, action groups, and curated Insights experiences that transform raw telemetry into actionable intelligence. Where LO1 taught you how to design the logging sink (Log Analytics workspace topology, retention, cost) and LO2 covered how to route logs to those sinks, this lesson is about what happens after the data arrives — how you surface health signals, detect anomalies, notify the right people, and trigger automated remediation. The exam tests your ability to choose among Azure Monitor metrics, the four Insights flavours (Application Insights, VM Insights, Container Insights, Network Insights), Service Health, alert rules, action groups, and Microsoft Defender for Cloud integration.

Scope discipline: This LO covers monitoring signals, alerts, and action groups: Azure Monitor metrics and dashboards, the Insights family (VM / Container / Network / Application), alert rules and action groups, Service Health, and Defender for Cloud integration. It is not about the logging sink (LO1) or log routing (LO2).

Reference: Ch. 1, §1.1, p. 8–16 of the AZ-305 exam book.

Why This Matters

Imagine you are the on-call architect for a financial-services company that just moved its core banking APIs to Azure. At 02:14 AM, response times spike to 12 seconds — but nobody finds out until customers start tweeting at 07:00 AM. The post-incident review reveals the team had logs flowing into a Log Analytics workspace (LO1, done correctly) and diagnostic settings routing data to the right destinations (LO2, also done correctly) — but nobody had configured an alert rule to fire when P95 latency exceeded 2 seconds, and there was no action group wired to a PagerDuty webhook. Logging without monitoring is like installing smoke detectors with no batteries.

The AZ-305 exam tests this exact gap. The exam book (Ch. 1 §1.1, p. 8–16) devotes a full section to monitoring tools because Microsoft considers it a discrete design decision: which signals to watch, which Insights experiences to enable, how to structure alert rules, and how to wire action groups into your incident-response workflow. This maps directly to the Well-Architected Framework's Operational Excellence and Reliability pillars — "can we detect degradation before customers do, and can we respond automatically?"

Prerequisites

• Log Analytics workspace fundamentals (LO1) — Can you describe what a workspace is, how data is ingested, and how KQL queries run against it? Self-check: what pricing model applies to a workspace ingesting 50 GB/day?
• Diagnostic settings and Data Collection Rules (LO2) — Do you know how platform logs and metrics flow from Azure resources to their destinations? Self-check: name the four possible destinations for a diagnostic setting.
• Azure Resource Manager hierarchy — Can you explain management groups, subscriptions, resource groups, and resources? Self-check: at which scope level does the Activity Log operate?
• Basic KQL syntax — Can you write a where + summarize query? Self-check: write a KQL query that returns the average DurationMs from AppRequests grouped by OperationName.

Learning Objectives

By the end of this lesson you will be able to:

1. Evaluate the core components of Azure Monitor — metrics, logs, alerts, and dashboards — and map each to the monitoring requirement it satisfies.
2. Recommend the appropriate Insights experience (Application Insights, VM Insights, Container Insights, Network Insights) for a given workload type and justify the choice based on the telemetry it collects.
3. Design an alerting strategy using metric alerts, log-search alerts, activity-log alerts, and Service Health alerts, selecting the right signal type for each scenario.
4. Construct action groups that combine notification channels (email, SMS, push) with automated response actions (Azure Function, Logic App, Automation Runbook, webhook) to close the detect-to-respond loop.
5. Analyse how Microsoft Defender for Cloud complements Azure Monitor by layering security-posture scoring and threat-detection alerts on top of operational monitoring.

Building Blocks

Azure Monitor — Analogy: think of a command centre with wall-mounted screens showing the vital signs of every system in the building — heart rate (metrics), security camera footage (logs), fire alarms (alerts), and a phone tree on the wall for who to call (action groups). → Formal definition: Azure's unified full-stack monitoring service that collects, analyses, and acts on telemetry from Azure resources, on-premises servers, and multicloud workloads. It stores numeric time-series data in a metrics store and semi-structured event data in Log Analytics workspaces. → Why it matters: every monitoring design decision in AZ-305 sits inside the Azure Monitor umbrella — metrics, Insights, alerts, action groups, and dashboards are all features of this single platform.

Metric — Analogy: a speedometer reading taken every minute — lightweight, numeric, and near-real-time. → Formal definition: a numeric time-series data point emitted by an Azure resource at regular intervals (typically 1-minute granularity) and stored in the Azure Monitor metrics store for 93 days by default. Metrics support dimensional filtering (e.g., by ResponseType, ApiName) and can be visualised in Metrics Explorer or pinned to Azure Dashboards. → Why it matters: metrics are the fastest signal path for detecting degradation — a metric alert can fire within 1–5 minutes of a threshold breach, far faster than a log-search alert.

Alert rule — Analogy: a smoke detector with a configurable sensitivity dial and a wired connection to the fire station. → Formal definition: an Azure Monitor resource that evaluates a condition against a signal (metric value, log-search result, activity-log event, or Service Health event) at a specified frequency and fires an alert when the condition is met. Each alert rule targets one or more action groups. → Why it matters: alert rules are the bridge between passive data collection and active incident response. Without them, telemetry is just data sitting in a store.

Action group — Analogy: an emergency phone tree — when the alarm rings, it simultaneously pages the on-call engineer, sends an SMS to the team lead, and triggers an automated runbook that restarts the failing service. → Formal definition: an Azure resource that defines a collection of notification preferences (email, SMS, push notification, voice call) and automated actions (Azure Function, Logic App, Automation Runbook, webhook, ITSM connector, Event Hub) that are invoked when an alert fires. Action groups are reusable across multiple alert rules. → Why it matters: the action group is where monitoring becomes operational — it closes the loop between detection and response.

Insights — Analogy: a pre-built, purpose-tuned dashboard that a specialist mechanic uses to diagnose a specific car model, versus a generic OBD-II code reader. → Formal definition: curated monitoring experiences within Azure Monitor that provide deep, workload-specific visualisations and analytics. The four Insights flavours — Application Insights, VM Insights, Container Insights, and Network Insights — each collect telemetry tailored to their workload type and surface it through purpose-built UIs. → Why it matters: Insights go beyond raw metrics and logs to deliver dependency maps, anomaly detection (Smart Detection), live metric streams, and topology views — capabilities that would take significant custom KQL development to replicate.

Service Health — Analogy: the weather forecast for Azure regions — it tells you about current storms (service issues), upcoming maintenance windows (planned maintenance), and long-range advisories (health advisories). → Formal definition: an Azure Monitor feature that provides personalised visibility into the health of Azure services in the regions and subscriptions you use. It covers three event types: service issues (outages), planned maintenance, and health advisories (deprecations, security bulletins). You can configure Service Health alerts to notify you proactively. → Why it matters: Service Health events are outside your control but inside your blast radius. Alerting on them lets your team distinguish between "our app is broken" and "Azure SQL in West Europe is degraded" — a critical triage distinction during incidents.

Deep Dive

Azure Monitor Metrics, Dashboards, and Workbooks

Azure Monitor collects two fundamental data types: metrics (numeric time-series stored in the metrics store) and logs (semi-structured records stored in Log Analytics workspaces). This lesson focuses on how you consume and act on that data — not how you route it there (LO2).

Metrics Explorer lets you chart any platform or custom metric, apply dimensional filters, and split by dimension. Pin favourite charts to an Azure Dashboard for a team-wide view.

Workbooks are interactive reports that combine metrics, logs, and parameters into a single canvas. They support KQL queries, Azure Resource Graph queries, and JSON data sources. Use workbooks for capacity-planning views or monthly operational reviews.

[!TIP] Pin your most critical Workbook to a shared Azure Dashboard and grant the operations team Reader access at the resource-group level. This avoids the common anti-pattern of building ad-hoc KQL queries during an incident.

The Insights Family — Choosing the Right Experience

The exam book (p. 10–13) describes four Insights experiences. Each is purpose-built for a workload type:

Application Insights deserves extra attention because it is the most feature-rich Insight and a frequent exam topic:

• Application Map — visualises inter-service dependencies and highlights error rates per component. Invaluable for diagnosing latency in distributed systems.
• Smart Detection — uses ML to automatically detect anomalies in failure rates, response times, and dependency durations. Sends email notifications without requiring manual alert-rule configuration.
• Live Metrics — a real-time stream of requests, failures, and performance counters with 1-second granularity. Zero storage cost — data is streamed directly to the portal without hitting the workspace.
• Availability Tests — synthetic HTTP probes from Azure edge locations that test whether your endpoint is reachable and responding within an expected time. Support URL ping tests and multi-step web tests.

[!IMPORTANT] Since 2024, workspace-based Application Insights is the only supported mode. Classic (standalone) Application Insights resources have been retired. Always link your Application Insights resource to a Log Analytics workspace.

Alert Rules — Signal Types and Evaluation

Azure Monitor supports four alert signal types, each suited to different scenarios:

Dynamic thresholds on metric alerts use ML to learn a metric's seasonal pattern and alert on deviations rather than fixed values. This is ideal for workloads with predictable diurnal patterns (e.g., CPU is normally 80% at noon but 20% at midnight — a static threshold of 85% would miss the midnight anomaly of 60%).

[!WARNING] Log-search alerts have a minimum evaluation frequency of 5 minutes and can take up to 15 minutes to fire after the underlying event occurs (ingestion delay + evaluation cycle). For time-critical signals like CPU exhaustion, use metric alerts instead — they evaluate every 1 minute with 1–5 minute total latency.

Action Groups — Closing the Detect-to-Respond Loop

An action group bundles two categories of response:

Design principles for action groups:

1. One action group per response persona — create ag-oncall-infra, ag-oncall-app, ag-security-team rather than one monolithic group. This lets you wire different alert rules to different teams.
2. Always include an automated action alongside a notification — a webhook to PagerDuty or a Logic App that creates a ticket ensures no alert is lost even if the email is missed.
3. Use the ITSM connector for enterprises with ServiceNow or System Center Service Manager — this auto-creates incidents and keeps the ITSM system of record in sync.
4. Test action groups with the Test button in the Azure portal before going live — a misconfigured webhook URL or an unverified email address silently drops notifications.

[!NOTE] The Common Alert Schema standardises the JSON payload sent to webhooks and Logic Apps across all alert types (metric, log-search, activity-log, Service Health). Enable it on every receiver to simplify downstream parsing.

Service Health and Defender for Cloud Integration

Service Health is not a separate product — it is a blade within Azure Monitor that surfaces three event categories:

Create a Service Health alert for each event type scoped to the regions and services your workloads use. Wire it to the operations team's action group so they can proactively communicate maintenance windows to stakeholders.

Microsoft Defender for Cloud complements operational monitoring with security-specific capabilities (exam book p. 14–15):

• Secure Score — a numeric posture rating (0–100%) based on how many security recommendations you have remediated.
• Security recommendations — actionable findings (e.g., "Enable disk encryption on VM vm-prod-01") with one-click remediation where possible.
• Threat-detection alerts — runtime alerts for suspicious activity (e.g., brute-force SSH attempts, anomalous Microsoft Entra ID sign-ins). These alerts appear in the Azure portal, can be forwarded to Microsoft Sentinel for SIEM correlation, and can trigger action groups.

Worked Examples

Easy — Single Web App with Availability Monitoring

Problem: Tailwind Traders runs a single App Service web application in East US. They want to know within 5 minutes if the site goes down and need historical uptime metrics for their monthly SLA report. Budget: minimal.

Step-by-step solution:

1. Enable workspace-based Application Insights on the App Service (auto-instrumentation — no code changes needed).
2. Configure an Availability Test (URL ping) from 5 Azure edge locations with a 5-minute frequency. This provides geographic coverage and avoids false positives from a single probe location.
3. Create a metric alert on the Application Insights metric availabilityResults/availabilityPercentage with a static threshold < 100% evaluated every 5 minutes over a 5-minute window.
4. Create an action group ag-webteam with an email notification to webteam@tailwindtraders.com and a webhook to their Slack channel.
5. For the monthly SLA report, create a Workbook that queries the availabilityResults table in the linked Log Analytics workspace and renders a 30-day uptime chart.

[!NOTE] Availability Tests are included in the Application Insights free tier for up to 10 tests. For a single app with 5 probe locations, there is zero additional cost.

Medium — Multi-Tier Application with VM and Container Workloads

Problem: Fabrikam runs a 3-tier application: a React frontend on App Service, a .NET API tier on Azure Kubernetes Service (AKS), and a backend on 3 Azure VMs running a legacy batch processor. They need end-to-end monitoring with dependency visibility. The operations team wants automated ticket creation in ServiceNow when critical alerts fire.

Step-by-step solution:

1. App tier: Enable Application Insights on the App Service (auto-instrumentation) and instrument the .NET API with the Application Insights SDK for distributed tracing.
2. Container tier: Enable Container Insights on the AKS cluster via the monitoring add-on. This deploys the containerised AMA agent and begins collecting node, pod, and container metrics into the shared Log Analytics workspace.
3. VM tier: Deploy Azure Monitor Agent (AMA) + Dependency Agent on all 3 VMs. Enable VM Insights to get performance charts and the dependency map showing inter-VM and VM-to-external connections.
4. Application Map: With all three tiers instrumented, Application Insights renders a full Application Map showing the React frontend → .NET API → backend VMs dependency chain with error rates per hop.
5. Alert rules:
   • Metric alert: AKS node CPU > 85% for 5 min → action group ag-oncall-infra.
   • Metric alert: App Service HTTP $5xx$ rate > 5% for 5 min → action group ag-oncall-app.
   • Log-search alert: VM Insights process crashes (InsightsMetrics | where Name == "Processor" and Val > 95) → action group ag-oncall-infra.
6. Action groups: Both ag-oncall-infra and ag-oncall-app include an ITSM action pointing to the ServiceNow connector for automated ticket creation, plus email and PagerDuty webhook.

[!NOTE] The Dependency Agent is required for VM Insights' dependency-map feature. Without it you get performance charts but no topology visualisation.

Hard — Enterprise Monitoring Strategy with Security Integration

Problem: Woodgrove Bank operates across 4 Azure regions with 200+ resources including VMs, AKS clusters, Azure SQL, App Services, and VPN Gateways. They need: (a) a single-pane-of-glass operational dashboard, (b) automated remediation for common failures, (c) security-posture scoring with threat alerts forwarded to Microsoft Sentinel, and (d) proactive notification of Azure service issues affecting their regions.

Step-by-step solution:

1. Insights enablement: Enable Application Insights on all App Services; Container Insights on all AKS clusters; VM Insights on all VMs and Arc-enabled servers; Network Insights for VNet, NSG, and VPN Gateway monitoring.
2. Centralised dashboard: Create a shared Azure Dashboard in the rg-monitoring resource group. Pin key Workbook tiles: P95 latency (Application Insights), node CPU heatmap (Container Insights), VM availability (VM Insights), network topology health (Network Insights).
3. Tiered alerting strategy:
   • P1 (Critical): Metric alerts for availability and latency; 1-min evaluation; action group with voice call + PagerDuty + Automation Runbook (auto-restart / auto-scale).
   • P2 (High): Log-search alerts for error-rate spikes and dependency failures; 5-min evaluation; action group with email + ServiceNow ticket.
   • P3 (Medium): Activity-log alerts for governance events (resource deletion, role assignment); action group with email to security team.
   • P4 (Informational): Service Health alerts for all 4 regions and all used service types; action group with email to operations lead + Logic App that posts to the #azure-status Teams channel.
4. Automated remediation: P1 action groups include an Automation Runbook that:
   • For VM CPU alerts: runs Restart-AzVM on the affected VM.
   • For App Service $5xx$ spikes: scales out the App Service Plan by 1 instance via Set-AzAppServicePlan.
5. Security integration: Enable Microsoft Defender for Cloud Standard tier for VMs, SQL, App Service, and Kubernetes. Configure continuous export of Defender alerts to the Microsoft Sentinel workspace. Create a Sentinel analytics rule that auto-creates incidents for high-severity Defender alerts.
6. Service Health: Create 4 Service Health alert rules (one per event type: service issue, planned maintenance, health advisory, plus one for security advisories) scoped to East US, West Europe, Southeast Asia, and Australia East.

[!NOTE] The Automation Runbook in step 4 should include a suppression window — after auto-restarting a VM, suppress the alert for 10 minutes to prevent a restart loop if the underlying issue persists.

Visual Explanations

Azure Monitor Architecture Overview (Mermaid)

Alert Signal Selection Decision Tree (Mermaid)

Insights Comparison Table

Action Group Anatomy (TikZ)

Alert Type Latency Comparison

Defender for Cloud Integration Points

Common Mistakes

❌ Myth: "I have Application Insights enabled, so I don't need metric alerts — Smart Detection will catch everything." ✅ Reality: Smart Detection uses ML to detect anomalies in failure rates, response times, and dependency durations — but it does not cover infrastructure metrics like CPU, memory, or disk. You still need explicit metric alerts for infrastructure health. Smart Detection also cannot trigger automated remediation actions — it only sends email notifications. Why it's tricky: Smart Detection feels like a comprehensive safety net because it requires no configuration. But it only covers application-level signals, not platform-level metrics.

❌ Myth: "Log-search alerts are better than metric alerts because KQL is more flexible." ✅ Reality: Log-search alerts offer richer query logic (joins, aggregations, regex) but have significantly higher latency (5–15 minutes) compared to metric alerts (1–5 minutes). For time-critical signals like CPU exhaustion, memory pressure, or availability drops, metric alerts are the correct choice. Use log-search alerts for complex conditions that cannot be expressed as a single metric threshold. Why it's tricky: KQL's power makes log-search alerts feel like the universal answer. The latency penalty is invisible until an incident exposes the 10-minute detection gap.

❌ Myth: "We configured email notifications in the action group — our alerting strategy is complete." ✅ Reality: Email-only alerting is the number-one cause of missed alerts. Emails get buried, filtered to spam, or arrive when the on-call engineer is asleep. A production-ready action group should include at least two notification channels (e.g., email + SMS or email + push) plus an automated action (e.g., PagerDuty webhook or ServiceNow ITSM connector) that creates a tracked incident. Why it's tricky: Email is the default notification type in the portal wizard, and adding a webhook or ITSM connector requires extra configuration that teams skip during initial setup.

❌ Myth: "Service Health alerts are optional — our monitoring already covers application health." ✅ Reality: Application-level monitoring cannot distinguish between "our code is failing" and "the Azure platform is experiencing an outage." Without Service Health alerts, your team wastes critical incident-response time debugging application code when the root cause is an Azure regional issue. Service Health alerts also warn you about upcoming planned maintenance so you can schedule failovers proactively. Why it's tricky: Service Health events are rare, so teams deprioritise configuring alerts for them — until the one time an Azure outage costs them hours of misdirected debugging.

Practice Exercises

🟢 Easy — Contoso has a single App Service web app. They want to know if the app goes down. Which monitoring tool should they enable first, and what specific feature within it provides synthetic uptime checks?

▶💡 Hint

Think about the Insight that is purpose-built for web applications. It has a feature that sends HTTP probes from Azure edge locations.

▶✅ Solution

Enable Application Insights (workspace-based) and configure an Availability Test (URL ping test) from at least 3 Azure edge locations. The Availability Test sends synthetic HTTP requests at regular intervals and records success/failure and response time. Create a metric alert on availabilityResults/availabilityPercentage < 100% to get notified of downtime.

🟢 Easy — What is the key difference between a metric alert and a log-search alert in terms of detection latency?

▶💡 Hint

Consider where each signal type is stored and how frequently the alert rule evaluates.

▶✅ Solution

Metric alerts evaluate every 1 minute against the near-real-time metrics store, with typical fire latency of 1–5 minutes. Log-search alerts run a KQL query against a Log Analytics workspace at a minimum frequency of 5 minutes, with typical fire latency of 5–15 minutes (including ingestion delay). For time-critical signals, metric alerts are preferred.

🟡 Medium — Fabrikam's operations team receives 200+ email alert notifications per day and has started ignoring them. Many are low-severity informational alerts mixed in with critical production issues. How should they restructure their alerting strategy?

▶💡 Hint

Think about alert severity levels, separate action groups per team, and the concept of alert-processing rules for suppression.

▶✅ Solution

1. Tier alerts by severity: Assign severity 0 (Critical) to availability and latency alerts; severity 1 (Error) to error-rate alerts; severity 2 (Warning) to capacity warnings; severity 3–4 to informational/verbose alerts.
2. Create separate action groups per persona: ag-oncall-critical (SMS + voice call + PagerDuty), ag-ops-high (email + ServiceNow), ag-ops-info (email-only to a shared mailbox).
3. Use alert-processing rules to suppress severity 3–4 alerts during maintenance windows.
4. Route critical alerts to a paid escalation service (PagerDuty, Opsgenie) that handles on-call rotation, escalation, and acknowledgement tracking. This reduces noise by ensuring only P1/P2 alerts wake people up, while lower-severity alerts are tracked via ticket system.

🟡 Medium — An AKS cluster running a microservices application is experiencing intermittent pod crashes. The team needs to see pod-level metrics, live container logs, and identify which nodes are under memory pressure. Which Insights experience should they enable, and what agent is required?

▶💡 Hint

Consider which Insight is purpose-built for Kubernetes workloads and how it is deployed.

▶✅ Solution

Enable Container Insights via the AKS monitoring add-on. This deploys a containerised Azure Monitor Agent that collects node metrics (CPU, memory, disk), pod metrics (restart count, status), and container logs. The Live Logs feature streams container stdout/stderr in real time for troubleshooting. Memory-pressure nodes are visible in the Node performance view. No manual agent installation is needed — the add-on handles deployment:

az aks enable-addons \ --resource-group rg-aks-prod \ --name aks-prod \ --addons monitoring \ --workspace-resource-id /subscriptions/{sub}/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/la-central-prod

🔴 Hard — Woodgrove Bank needs to design a monitoring strategy that covers: (a) application latency and dependency health for their APIs, (b) infrastructure health for 50 VMs, (c) security-posture scoring, and (d) automated VM restart when CPU exceeds 95% for 10 minutes. Design the complete monitoring architecture.

▶💡 Hint

You need multiple Insights experiences, tiered alert rules, action groups with both notifications and automated actions, and Defender for Cloud.

▶✅ Solution

1. Application Insights (workspace-based) on all API App Services for application map, smart detection, availability tests, and distributed tracing.
2. VM Insights on all 50 VMs with AMA + Dependency Agent for performance monitoring and dependency maps.
3. Metric alert on VM Percentage CPU > 95%, window 10 min, evaluation every 1 min. Action group ag-auto-remediate includes:
   • Notification: Email + SMS to on-call
   • Action: Automation Runbook Restart-AzVM with the affected VM's resource ID passed via Common Alert Schema payload
4. Alert-processing rule: After auto-restart, suppress the CPU alert for the affected VM for 15 minutes to prevent restart loops.
5. Microsoft Defender for Cloud Standard tier enabled for VMs and SQL. Continuous export configured to send high-severity threat alerts to the Sentinel workspace.
6. Service Health alerts scoped to the bank's 2 active regions for all event types.
7. Centralised Azure Dashboard with pinned Workbook tiles from Application Insights (P95 latency), VM Insights (top-10 CPU heatmap), and Defender (Secure Score trend).

🔴 Hard — An Azure SQL Database is experiencing intermittent query timeouts. The DBA team needs to monitor DTU consumption, identify long-running queries, and get alerted when DTU usage exceeds 90% for more than 5 minutes. Which combination of monitoring tools and alert types should they use?

▶💡 Hint

Azure SQL exposes DTU metrics natively. Long-running query analysis requires log-level data.

▶✅ Solution

1. Metric alert: Create a metric alert on dtu_consumption_percent > 90%, time aggregation Average, window size 5 minutes, evaluation frequency 1 minute. Wire to ag-dba-team (email + SMS + ServiceNow ticket).
2. Log-search alert: Configure a diagnostic setting to send QueryStoreRuntimeStatistics to the central Log Analytics workspace. Create a log-search alert:

AzureDiagnostics | where ResourceType == "SERVERS/DATABASES" | where Category == "QueryStoreRuntimeStatistics" | where duration_d > 30000 | summarize LongQueryCount = count() by bin(TimeGenerated, 5m) | where LongQueryCount > 5

This fires when more than 5 queries exceed 30 seconds in a 5-minute window. 3. Azure SQL Analytics (a monitoring solution in the Azure Marketplace) provides a pre-built dashboard for DTU trends, wait statistics, and intelligent performance insights. 4. Defender for SQL for anomalous access pattern detection (SQL injection attempts, unusual data export).

Summary & Concept Map

• Azure Monitor is the unified platform — metrics store for fast numeric signals, Log Analytics workspace for rich log queries, and alert rules to bridge detection to response.
• Metric alerts fire in 1–5 minutes (use for time-critical thresholds); log-search alerts fire in 5–15 minutes (use for complex KQL conditions); activity-log alerts and Service Health alerts are event-driven and near-real-time.
• The Insights family provides curated, workload-specific monitoring: Application Insights for web apps (Application Map, Smart Detection, Availability Tests), VM Insights for VMs (dependency map), Container Insights for AKS (pod metrics, live logs), Network Insights for network resources (topology, connectivity, traffic).
• Action groups should combine notifications (email + SMS) with automated actions (webhook, Runbook, Logic App) — email-only alerting is an anti-pattern.
• Service Health alerts distinguish Azure platform issues from application bugs — configure them for every region and service your workloads use.
• Microsoft Defender for Cloud layers security-posture scoring (Secure Score) and threat-detection alerts on top of operational monitoring. Forward Defender alerts to Microsoft Sentinel for SIEM correlation.
• Design alerting in severity tiers (P1–P4) with separate action groups per response persona to prevent alert fatigue.