2.1 Logging Solution Design
Key Takeaways
- Azure Monitor splits data into two platforms: Metrics (automatic, numeric time-series) and Logs (requires a Log Analytics workspace and KQL)
- Diagnostic settings are the only way to export resource logs into a workspace, are forward-only, and support up to 5 per resource with one destination of each type
- Table plans (Analytics/Basic/Auxiliary) trade off ingestion cost, query power, and retention -- match the plan to how often the data is queried and alerted on
- The Activity Log only records control-plane operations (create/delete/modify), never data-plane events like CPU spikes or app exceptions
- Long-term retention can extend to 12 years (4,383 days), but archived data requires a search job to become interactively queryable again
Why This Topic Matters on AZ-305
Design solutions for logging and monitoring anchors Domain 1 (Design identity, governance, and monitoring solutions), the exam's second-largest domain at 25-30% of the AZ-305 score. Logging design is also the quietest cross-cutting skill on the exam: nearly every scenario in the Data Storage, Business Continuity, and Infrastructure domains eventually asks "how would you know if this failed?" If you cannot reason correctly about Azure Monitor's two data platforms and how diagnostic settings move data between them, you will also miss points buried inside unrelated-looking questions about databases, VMs, and networking.
Core Concepts: Two Data Platforms, One Front Door
Azure Monitor collects data into two platforms, and AZ-305 scenario questions frequently hinge on knowing which platform a given piece of data lives in:
- Metrics — lightweight, numeric time-series data (for example, CPU percentage, queue length). Platform metrics are collected automatically at roughly one-minute granularity with no configuration required and are retained for a fixed window measured in months, viewable immediately in Metrics Explorer.
- Logs (Azure Monitor Logs) — structured event records queried with Kusto Query Language (KQL) inside a Log Analytics workspace (LAW). Logs are not collected automatically; you must explicitly configure collection.
The bridge between raw platform data and a workspace is the diagnostic setting. A diagnostic setting is a per-resource configuration object that says "take this data, send it to these destinations." It can capture three source types:
| Source | Collected by default? | What it contains |
|---|---|---|
| Platform metrics | Yes (viewable in Metrics Explorer) | Numeric time series; a diagnostic setting only exports a copy into logs-based destinations |
| Activity log | Yes (subscription-level, 90-day retention) | Control-plane operations — who created/deleted/modified a resource — never data-plane operations |
| Resource logs | No | Service-specific operational data (for example, Key Vault access events, NSG flow logs, SQL query performance data) |
Exam trap: the Activity Log only records management-plane actions (an ARM PUT/DELETE/PATCH against a resource). It never shows you that a virtual machine's CPU spiked or that an application threw an exception — those are resource logs and metrics, which require a diagnostic setting to persist into a workspace for historical querying.
Log Analytics Workspace Design
A Log Analytics workspace is both the storage container and the KQL query engine for Azure Monitor Logs. Two workspace-design decisions repeatedly appear on AZ-305:
- Centralized vs. per-team/per-subscription workspaces. One centralized workspace simplifies cross-resource KQL correlation and consolidated alerting, but it mixes data ownership and access boundaries across teams. Separate workspaces isolate access control and cost allocation per team but complicate any query that needs to span them. Azure Monitor's access control mode lets a workspace require workspace-context permissions (broad access to all tables) or resource-context permissions (a user only sees data from resources they can already read) — choose resource-context when regulatory or organizational boundaries require it inside a shared workspace.
- Table plan selection. Every table in a workspace runs on a plan that trades off cost, query power, and retention:
| Plan | Ingestion cost | Query capability | Default interactive retention | Best for |
|---|---|---|---|---|
| Analytics | Standard (highest) | Full KQL, supports alerting, workbooks, dashboards | 30 days (extendable up to 730 days) | Security, operational, and alerting data you query often |
| Basic | Substantially lower | Limited KQL, no alerting on the table directly | Fixed 30 days | High-volume verbose diagnostic/debug logs queried occasionally |
| Auxiliary | Lowest | Very limited query, no alerting | Total retention period only (queryable via search jobs) | Extreme-volume compliance/audit data rarely queried |
A table can be extended with long-term (archive) retention up to 12 years (4,383 days) at low cost regardless of plan; archived data is not interactively queryable until you run a search job that rehydrates the needed slice into a temporary results table. Two tables always keep 90 days free by default, regardless of workspace setting: Usage and AzureActivity. Application Insights App* tables (AppRequests, AppExceptions, AppDependencies, and others) also default to 90-day free retention.
Design Constraints You Must Know
- Up to five diagnostic settings per resource, and a single setting can define at most one of each destination type — if a design calls for two Log Analytics workspaces (for example, one regional operational workspace and one central security workspace), you need two separate diagnostic settings on that resource.
- Regional destinations (storage accounts, Event Hubs) must sit in the same region as the monitored resource when that resource is regional.
- After a diagnostic setting is created, data typically starts flowing within about 90 minutes; nothing is backfilled — diagnostic settings are forward-only.
- Metrics exported through a diagnostic setting are flattened: multi-dimensional metrics lose their per-dimension breakdown and are aggregated when they land in a workspace.
Scenario Walkthrough
A retail company runs workloads across 40 subscriptions. The security team wants one place to run KQL threat-hunting queries across every subscription, while each application team wants to troubleshoot only their own resources without seeing other teams' data. The correct design uses one centralized Log Analytics workspace with the access control mode set to resource-context permissions, so RBAC on each individual resource — not workspace membership — determines what a given engineer can query, while the security team (granted workspace-level read access) still sees everything centrally.
Key Takeaways
- Metrics and Logs are two distinct Azure Monitor data platforms; only Logs require a Log Analytics workspace and KQL.
- Diagnostic settings are the only mechanism to export resource logs, and they are forward-only — never retroactive.
- Centralize workspaces for cross-cutting KQL and alerting; use resource-context access control mode to preserve per-team data boundaries within that same workspace.
- Match each table's plan (Analytics/Basic/Auxiliary) to how often it needs to be queried and alerted on, not just its volume.
- Long-term retention (up to 12 years) is cheap but not interactively queryable without a search job.
An architect needs a table in a Log Analytics workspace to hold nine months of rarely-queried, high-volume raw firewall logs as cheaply as possible, with occasional forensic search capability. Which table plan best fits this requirement?
A resource already has diagnostic settings sending logs to one Log Analytics workspace and one storage account. The design now requires also streaming the same logs to a second Log Analytics workspace dedicated to the security team. What must the architect do?
A company wants to know whenever an administrator deletes a virtual machine, but that information never appears in their Log Analytics resource logs table. Where should they look instead?