Episode 3 — Logs, the Log Analytics Workspace & KQL
Series: AZ-104 · Monitor and Maintain Azure Resources — micro-learning. Where we are: After Episode 2 covered the numeric, real-time world of Metrics, we now enter the other half of the data platform — Logs, the Log Analytics workspace (LAW) that stores them, and the KQL you use to interrogate them; next comes Episode 4 on how data actually gets in.
Why it matters
Azure Monitor Logs is the centralized SaaS platform for collecting, analyzing, and acting on telemetry from Azure and non-Azure resources. Everything lands in one Log Analytics workspace so you never move data or manage other storage — but that means the workspace's tables, table plans, retention, and access are yours to design, and on the exam they map directly to cost and capability.
Learning objectives
- By the end, you can explain how a Log Analytics workspace stores data as tables and why you never move data between stores.
- By the end, you can choose the correct table plan (Analytics / Basic / Auxiliary) for a workload and predict its capabilities.
- By the end, you can distinguish interactive retention from long-term retention and quote the default and maximum values.
- By the end, you can describe the access control mode and the workspace transformation DCR at a high level.
- By the end, you can say where KQL runs, use Simple mode vs KQL mode, and name the operators exclusive to Azure Monitor.
1. The mental model: one workspace, many tables
Recall the Episode 1 split — Metrics vs Logs. Metrics live in a time-series database (Episode 2); Logs live in a Log Analytics workspace, the primary Azure Monitor Logs resource.
- A LAW is a data store that holds tables into which you collect data.
- Azure Monitor automatically creates tables for the monitoring data collected from your Azure environment.
- You create custom tables for data from non-Azure resources and applications.
- Table management settings control access, data model, retention, and cost per table.
Mnemonic — "one lake, many buckets": the workspace is a single lake; each table is a bucket you tune independently. You dip into buckets with queries; you never haul the water somewhere else.
2. Table plans — the cost/capability dial
Table plans let you manage data cost based on how often you use the data and what analysis you need. Memorize the trio.
| Feature | Analytics | Basic | Auxiliary |
|---|---|---|---|
| Best for | High-value data for continuous monitoring, real-time detection, performance analytics | Medium-touch data for troubleshooting and incident response | Low-touch verbose logs, auditing and compliance |
| Supported table types | All table types | Azure tables that support Basic + DCR-based custom tables | DCR-based custom tables only |
| Ingestion cost | Standard | Reduced | Minimal |
| Query price included | Yes | No | No |
| Query performance | Optimized | Optimized | Slower — good for auditing, not real-time |
| Query capabilities | Full KQL | Full KQL on a single table, extend via lookup to an Analytics table | Full KQL on a single table, extend via lookup |
| Alerts | Yes | Yes (Simple Log Alerts) | No |
| Insights | Yes | No | No |
| Dashboards | Yes | Yes (refresh query cost not included) | Possible, but slow to refresh |
| Data export | Yes | Yes | No |
| Restore | Yes | Yes | No |
| Search jobs | Yes | Yes | Yes |
Note: Basic and Auxiliary plans aren't available on legacy pricing tiers. Auxiliary does not currently support workspace replication or Customer Lockbox.
Mnemonic — A/B/C by touch: Analytics = high-touch (all features, you pay to query freely); Basic = medium-touch (cheaper in, pay per query, single-table); Auxiliary = the "Cold attic" of verbose audit logs (cheapest, slowest, custom tables only).
3. Retention — two states, two clocks
A workspace retains data in two states.
| State | What it enables | Key numbers |
|---|---|---|
| Interactive retention | Query, alerts, visualizations, and other features (per table plan) | Analytics default = 30 days (90 days for Microsoft Sentinel and Application Insights); extendable up to 2 years at a prorated long-term charge |
| Long-term retention | Low-cost archive; pull data back with a search job | Total retention up to 12 years for any table |
- You manage log data in one place — no moving to external storage — and get full analytics on older data when you run a search job to bring it back into interactive retention.
4. Access, transformation & cost
- Data access is defined by the access control mode setting on each workspace. Either give users explicit workspace access via a built-in or custom role, or grant resource-context access so users who can see an Azure resource can see the data it collected.
- Workspace transformation DCR (previewed here; full DCRs in Episode 4): one per workspace, defined per table, applying to data not already sent via a DCR — e.g. diagnostic-settings resource logs. Use it to filter records you don't need and cut ingestion cost.
- Cost: there is no charge to create or maintain a workspace. You pay for data ingestion + data retention, based on each table's table plan.
5. Workspace architecture
- A single workspace works for all your data collection.
- Use multiple workspaces for compliance/data-residency (store data in specific regions), split billing, and resilience.
- Use Log Analytics Workspace Insights to monitor workspace usage, performance, health, ingestion, queries, and change log.
6. KQL and the Log Analytics tool
Azure Monitor Logs is built on Azure Data Explorer and uses the same Kusto Query Language (KQL). KQL queries in Log Analytics are read-only requests.
Log Analytics is the portal tool for running queries. Two ways to drive it:
| Mode | Who it's for | How it works |
|---|---|---|
| Simple mode | Any user, no KQL needed | Retrieve data from one or more tables with one click; explore in a spreadsheet-like experience |
| KQL mode | Users who know KQL | Edit/create queries, then reuse them in alerts, workbooks, or share them |
Where you use queries: Log Analytics · log search alert rules (Episode 5) · workbooks · Azure dashboards · Azure Logic Apps · PowerShell (Invoke-AzOperationalInsightsQuery) · the Log Analytics query API.
Important: since July 1, 2025, querying via the query API requires TLS 1.2 or higher (Log Analytics or Application Insights).
A tiny query reads table → filter → aggregate:
Heartbeat
| where TimeGenerated > ago(1h)
| summarize count() by Computer
Language differences (Azure Monitor vs Azure Data Explorer)
| Not supported in Azure Monitor | Exclusive to Azure Monitor |
|---|---|
| Statements: Alias, Query parameters | workspace() — query across workspaces |
Functions: cluster(), database(), current_principal(), extent_id(), cursor functions | app() — query across classic Application Insights apps |
| Operator: Cross-Cluster Join | resource() — correlate data between resources |
| Plug-ins: Python plugin, sql_request plugin |
Numbers & names to memorize
| Item | Value |
|---|---|
| Primary Logs resource | Log Analytics workspace |
| Analytics interactive retention (default) | 30 days |
| Interactive retention for Sentinel / App Insights | 90 days |
| Max interactive retention (extended) | 2 years |
| Total (long-term) retention, any table | up to 12 years |
| Bring archived data back to interactive | search job |
| Table plans | Analytics · Basic · Auxiliary |
| Auxiliary supports | DCR-based custom tables only |
| Plans not on legacy tiers | Basic & Auxiliary |
| Access setting | access control mode (per workspace) |
| Query language / engine | KQL on Azure Data Explorer |
| Query API requirement (since Jul 1 2025) | TLS 1.2+ |
| PowerShell query cmdlet | Invoke-AzOperationalInsightsQuery |
| Azure-Monitor-exclusive operators | workspace(), app(), resource() |
Apply it
Scenario 1. Your team ingests very verbose firewall audit logs (rarely queried, kept for compliance) into a custom table, plus key security events used in daily monitoring and alerting. Which table plan do you set on each, and why?
Scenario 2. Finance says the workspace bill is too high because diagnostic-settings resource logs are flooding a table with records you never query. Data comes from diagnostic settings, not the Azure Monitor Agent. What can you configure to cut ingestion cost, and where?
MCQ 1. A table on the Auxiliary plan is required. Which is TRUE? (single answer)
- A. It supports all table types including auto-created Azure tables.
- B. It supports log search alerts with fast, real-time queries.
- C. It supports only DCR-based custom tables and has minimal ingestion cost with slower queries.
- D. It is available on legacy pricing tiers.
MCQ 2. Which are exclusive to Azure Monitor KQL and not general Azure Data Explorer KQL? (multi-select — choose all that apply)
- A.
workspace() - B.
cluster() - C.
app() - D.
resource()
Answers
- Scenario 1: Put the verbose compliance logs on Auxiliary (minimal ingestion cost, DCR-based custom table, audit-oriented slow queries); put the daily security/alerting events on Analytics (full features, alerts, insights, query included).
- Scenario 2: Create a workspace transformation DCR with a per-table transformation that filters the resource-log table — it applies because diagnostic-settings data doesn't already use its own DCR, cutting ingestion cost.
- MCQ 1: C — Auxiliary = DCR-based custom tables only, minimal cost, slower queries, no alerts, and not on legacy tiers.
- MCQ 2: A, C, D —
workspace(),app(), andresource()are Azure-Monitor-exclusive;cluster()is not supported in Azure Monitor.
Recap
- The Log Analytics workspace is the primary Logs resource — one store, many tables, and you never move data.
- Table management (access, data model, retention, cost) is set per table; the lever is the table plan.
- Analytics / Basic / Auxiliary trade cost for capability — full features vs cheaper single-table vs minimal-cost audit.
- Retention has two clocks: interactive (default 30 days, 90 for Sentinel/App Insights, up to 2 years) and long-term (up to 12 years, restored via search job).
- Access control mode governs who sees data; a workspace transformation DCR filters non-DCR sources to save cost.
- KQL on Azure Data Explorer powers everything; use Simple mode without KQL or KQL mode to author; remember
workspace(),app(),resource().
Next up
Continue to Episode 4 — the data-collection pipeline: activity log, resource logs, diagnostic settings, the Azure Monitor Agent, and the data collection rules (DCRs) that decide how telemetry actually reaches these tables.