1. Azure Monitor Architecture

  • Metrics — Numeric time-series stored in a fast, 93-day retention store. Near real-time (1-min granularity). Ideal for autoscale and metric alerts.
  • Logs — Rich structured/semi-structured data ingested into Log Analytics workspaces. Query with KQL; retention 30–730 days (or Archive up to 12 years).
  • Data sources — Azure resources (platform metrics/logs), VMs (AMA agent), apps (Application Insights), custom (REST API, Event Hubs).
  • Sinks — Workbooks, dashboards, alerts, Power BI, Sentinel, Event Hubs export, Storage Account archive.
VMs / Apps / PaaS / Custom
↓ Data Collection Rules (DCR)
Log Analytics Workspace
Metrics Store
↓ Consume
Alerts / Action Groups
Workbooks / Dashboards
Sentinel SIEM

2. Workspace Topology Design

Topology
Pros
Cons
Best For
Centralized (single)
Unified querying; volume discounts; simpler management
Blast-radius risk; complex RBAC; data-sovereignty issues
Single-region, single-compliance orgs
Decentralized (per-team)
Team autonomy; natural access boundary; data isolation
Cross-team correlation hard; cost duplication; no volume discounts
Regulated teams with strict data isolation
Hybrid (central + satellite)
Central SOC view + team ownership; Sentinel on central; cross-workspace queries
More complex design; cross-workspace query cost
Large enterprises (20+ teams), multi-region

3. Workspace Design Decisions

  • Retention — Default 30 days (free); interactive up to 730 days (pay per GB/month); Archive tier for compliance up to 12 years.
  • Data Collection Rules (DCR) — Filter and transform data at ingestion; reduce cost by dropping verbose columns; route different tables to different workspaces.
  • Table plans — Analytics (full KQL), Basic (limited queries, 8-day retention, lower cost), Archive (restore on demand).
  • Sentinel integration — Sentinel sits atop a workspace; use a dedicated workspace or share with IT ops. Dedicated avoids noisy neighbor queries but adds cost.
  • Access control — Workspace-level RBAC, resource-context RBAC (users see only logs from resources they own), or table-level RBAC for sensitive tables (e.g., SecurityEvent).

4. KQL for Architects

You won't write production queries daily, but you must design workbooks and alerts. Key patterns:

// Summarize — aggregate for dashboards
AzureActivity
| where TimeGenerated > ago(7d)
| summarize count() by ResourceGroup, OperationNameValue
| order by count_ desc

// Join — correlate across tables
Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| join kind=leftouter (
    Perf | where CounterName == "% Processor Time"
    | summarize AvgCPU = avg(CounterValue) by Computer
) on Computer

// Render — visualization for workbooks
Perf
| where CounterName == "Available MBytes"
| summarize avg(CounterValue) by bin(TimeGenerated, 5m), Computer
| render timechart
  • Architect tip: Design alert KQL to return a numeric threshold (e.g., | summarize AggregatedValue = count()) for log alert rules.
  • Use workspace('name').Table for cross-workspace queries in hybrid topologies.

5. Alert Architecture & Action Groups

  • Metric alerts — Evaluate every 1–5 min; stateful (fire once, auto-resolve). Best for resource health (CPU, DTU, latency).
  • Log alerts — KQL query on schedule (5–15 min). Best for complex conditions across tables/resources.
  • Activity log alerts — Triggered by control-plane events (e.g., VM deallocated, policy non-compliant). Zero cost.
  • Action groups — Bundle notification targets: email, SMS, push, voice, webhook, ITSM connector, Logic App, Azure Function, Event Hub.
  • ITSM integration — Connect to ServiceNow/BMC via ITSM Connector or webhook; auto-create incidents with severity mapping.
  • Design pattern — Tiered action groups: P1 (PagerDuty + phone), P2 (Teams channel + email), P3 (ticket only).

6. Real-World: 20-Team Enterprise Monitoring

Scenario: A financial services company with 20 product teams across 3 regions needs unified observability while maintaining team autonomy and regulatory compliance.

  • Topology: Hybrid — one central SOC workspace (Sentinel-enabled) + 4 regional workspaces for team data. Cross-workspace queries federate views.
  • DCRs: All security logs route to SOC workspace; performance/app logs stay in regional workspaces. Transform rules strip PII before ingestion.
  • Access: Resource-context RBAC lets developers see their own resource logs. SOC analysts get workspace-level read on central. Table-level RBAC restricts SecurityEvent to SecOps.
  • Alerts: Central alert rules for security (P1 → PagerDuty). Team-owned alert rules for app health (P2 → Teams). Shared action groups for common ITSM ticketing.
  • Cost control: Basic table plan for verbose diagnostic logs; commitment tier on central workspace (300 GB/day); archive for audit logs beyond 90 days.

💡 Exam Tip

AZ-305 loves workspace topology questions. Remember: choose centralized when cross-team correlation matters and costs must be optimized; choose decentralized when data sovereignty or strict isolation is required. Resource-context RBAC is the key to giving teams access in a shared workspace without exposing other teams' data.

🧪 Knowledge Check