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').Tablefor 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.