This chapter covers Azure Log Analytics and Log Analytics Workspaces, a core monitoring service under the Azure Management Governance domain. For AZ-900, this objective (3.3) tests your understanding of how Azure collects, stores, and analyzes log data from various resources. Governance and monitoring questions typically make up 15-20% of the exam, and Log Analytics is a key component. You'll learn what a Log Analytics workspace is, how it ingests data, how to query logs using Kusto Query Language (KQL), and how it integrates with other monitoring tools like Azure Monitor. By the end, you'll be able to explain the role of Log Analytics in centralized logging and troubleshooting, which is essential for both the exam and real-world Azure administration.
Jump to a section
Imagine your company's IT infrastructure is a large office building with many rooms, each containing different equipment (servers, databases, network switches). You need to know what's happening in each room: who enters, when devices overheat, or if a door is left open. Hiring a guard for every room is expensive and doesn't give you the full picture. Instead, you hire a detective agency that places tiny sensors in every room, on every door, and on every piece of equipment. These sensors send constant updates to a central command center, where a team of analysts logs every event, correlates patterns, and creates dashboards showing real-time activity. When something unusual happens—like a server room door opening at 3 AM—the command center alerts you immediately. You can also go back and review any past event, like a power outage last Tuesday, by asking the analysts to search their logs. The agency charges based on how much data you store and how long you keep it. In Azure, Log Analytics works exactly like this: agents (sensors) collect data from your resources, send it to a Log Analytics workspace (command center), where you can query, analyze, and set alerts. You pay for data ingestion and retention, and you can keep logs for up to two years (or longer with archive).
What is Azure Log Analytics and Why Does It Exist?
Azure Log Analytics is a service within Azure Monitor that collects, indexes, and stores telemetry data from Azure resources, on-premises machines, and other cloud environments. It provides a central location to query and analyze log data, enabling you to identify issues, detect patterns, and gain operational insights. The business problem it solves is the challenge of managing logs from hundreds or thousands of distributed resources—without a centralized logging solution, IT teams would have to log into each server or service individually, wasting time and missing critical correlations.
How It Works: The Data Pipeline
Log Analytics works through a data pipeline with three main stages: ingestion, storage, and query.
Ingestion: Data sources (e.g., Azure VMs, custom applications, Azure Activity Log) send logs to a Log Analytics workspace via agents (Azure Monitor Agent, Log Analytics agent) or APIs. Each log entry is formatted as a JSON record with timestamps and properties.
Storage: Ingested data is stored in tables within the workspace. Each data source maps to a specific table (e.g., Perf for performance counters, Event for Windows event logs). Data is indexed for fast queries.
Query: Users write queries in Kusto Query Language (KQL) to search, filter, aggregate, and visualize log data. Results can be viewed in the Azure portal, exported to Power BI, or used to trigger alerts.
Key Components
Log Analytics Workspace: A logical container for log data. Each workspace has its own data repository, configuration, and permissions. You can have multiple workspaces for different environments (e.g., dev, test, prod).
Data Sources: Sources that send logs to the workspace: Azure resources (via diagnostic settings), virtual machines (via agents), Azure Activity Log, Azure AD logs, and custom logs from applications.
Agents: Software that collects data from operating systems. The newer Azure Monitor Agent (AMA) replaces the legacy Log Analytics agent. AMA supports Windows and Linux and uses data collection rules (DCRs) to define what data to collect.
Kusto Query Language (KQL): A read-only query language optimized for log analytics. It resembles SQL but is designed for large volumes of time-series data. Example: Perf | where CounterName == "% Processor Time" | summarize avg(CounterValue) by Computer.
Log Analytics Workspace Insights: A pre-built monitoring experience that uses KQL queries to provide dashboards for specific services like Azure Key Vault or Azure Storage.
Pricing Tiers and Retention
Azure Log Analytics offers two pricing tiers:
Pay-as-you-go (Per GB): You pay for the volume of data ingested (in GB) and for data retention beyond the free first 31 days. Standard retention is 31 days for most tables, but you can configure up to 730 days (2 years) for a per-GB fee.
Commitment Tiers: You commit to a daily data volume (100 GB/day, 500 GB/day, etc.) for a discount compared to pay-as-you-go. If you exceed the commitment, you pay the pay-as-you-go rate for the overage.
Data retention can be set per table. You can also enable Long-Term Retention for up to 7 years by archiving data to Azure Storage. Archiving is cheaper but querying archived data requires restoring it first.
How It Compares to On-Premises Logging
In an on-premises environment, you might use tools like Splunk or ELK Stack (Elasticsearch, Logstash, Kibana). Azure Log Analytics is similar but fully managed—no need to provision servers, manage clusters, or scale storage. It integrates natively with Azure resources, so enabling diagnostics for a VM or web app automatically sends logs to the workspace. The on-premises equivalent requires manual setup of log shippers, central servers, and storage. Azure also offers built-in AI (via Azure Monitor) to detect anomalies, which on-premises tools often require add-ons.
Azure Portal and CLI Touchpoints
In the Azure portal, you can create a Log Analytics workspace by searching for "Log Analytics workspaces" and clicking "Create." You must specify a subscription, resource group, name, and region. Once created, you can configure data sources via the workspace's menu (e.g., "Agents management" for VMs, "Activity log" for subscription-level events).
Using Azure CLI, you can create a workspace with:
az monitor log-analytics workspace create --resource-group myRG --workspace-name myWorkspace --location eastusTo list workspaces:
az monitor log-analytics workspace list --resource-group myRGTo query logs, you use the Azure portal's Logs blade or the CLI with az monitor log-analytics query:
az monitor log-analytics query --workspace myWorkspace --query "Perf | where CounterName == '% Processor Time' | take 10"Integration with Azure Monitor
Log Analytics is the data store for Azure Monitor's logging capabilities. Azure Monitor collects metrics (numerical values) and logs (event records). Metrics are stored in a time-series database, while logs are stored in Log Analytics. You can use Log Analytics to query both types of data by using the metrics table (for metric data) or by joining log tables. Alerts can be created based on log queries, sending email or triggering automation.
Concrete Business Scenarios
Scenario 1: A company runs 200 VMs in Azure. They need to track CPU usage across all VMs to identify over-provisioned instances. They enable the Azure Monitor Agent on each VM with a data collection rule that collects performance counters. All data flows to a Log Analytics workspace. An administrator writes a KQL query: Perf | where CounterName == "% Processor Time" | summarize avg(CounterValue) by Computer | top 10 by avg_CounterValue desc. This shows the top 10 VMs by average CPU usage, allowing the team to downsize or scale out.
Scenario 2: An e-commerce application logs errors to a custom table in Log Analytics. The operations team sets up a log alert that triggers when more than 5 errors occur in 5 minutes. The alert sends an email to the on-call engineer and runs an Azure Automation runbook to restart the web app. This minimizes downtime.
Scenario 3: A security team needs to audit user sign-ins. They send Azure AD sign-in logs to a Log Analytics workspace. They create a query that flags sign-ins from unusual locations or after hours. The team reviews these daily to detect potential breaches.
Common Pitfalls
Excessive data ingestion: Without proper filtering, you can ingest terabytes of logs, increasing costs. Use data collection rules to limit what data is sent.
Incorrect retention settings: Default retention is 31 days. If you need longer, configure it per table; otherwise, older data is automatically deleted.
Workspace location: Choose a region close to your resources to reduce latency and egress costs. Log Analytics workspaces are region-specific; data does not automatically replicate across regions (unless you configure export).
Create a Log Analytics Workspace
In the Azure portal, search for 'Log Analytics workspaces' and click 'Create'. Fill in the subscription, resource group, workspace name, and region. The workspace name must be unique within a resource group. Choose a region close to your monitored resources to minimize latency. Click 'Review + Create' then 'Create'. Behind the scenes, Azure provisions a dedicated data ingestion and storage endpoint. The workspace is assigned a workspace ID and a primary key that agents use to authenticate. There is no cost for the workspace itself; you pay only for ingested data and retention. Default retention is 31 days for all tables, but you can change this per table later. This step is foundational—all log data flows into this container.
Configure Data Sources
After creating the workspace, you need to connect data sources. For Azure resources (VMs, App Services, etc.), enable diagnostic settings: navigate to the resource, click 'Diagnostic settings', then 'Add diagnostic setting'. Select the logs and metrics you want to send, and choose 'Send to Log Analytics workspace' and pick your workspace. For on-premises or non-Azure VMs, install the Azure Monitor Agent (AMA) on each machine. AMA uses data collection rules (DCRs) to specify what data to collect (e.g., performance counters, event logs). DCRs are created in Azure and associated with the workspace. You can also stream Azure Activity Log (subscription-level events) to the workspace by configuring diagnostic settings on the subscription. Each data source maps to a specific table in the workspace (e.g., `Perf`, `Event`, `AzureActivity`).
Query Logs Using KQL
Open the Log Analytics workspace in the portal and click 'Logs'. This opens the query editor. Write a KQL query to filter, aggregate, or join data from one or more tables. For example, to see all error events from the last hour: `Event | where EventLevelName == "Error" | where TimeGenerated > ago(1h)`. KQL is case-sensitive and uses a pipe (|) to chain operators. Common operators include `where` (filter), `project` (select columns), `summarize` (aggregate), and `join`. You can run the query and view results as a table or chart. Queries can be saved, shared, or used to create alerts. The query engine is optimized for large datasets; it uses indexes and partitions to return results quickly. You can also export results to CSV or Power BI.
Set Up Alerts
From a log query, you can create a log alert rule. Click 'New alert rule' in the query editor. Define the condition: e.g., if the number of results is greater than 0. Set the evaluation frequency (e.g., every 5 minutes) and the window of time to look back (e.g., 15 minutes). Then configure actions: send an email, trigger an Azure Function, or run a webhook. The alert rule is saved as an Azure Monitor resource. Behind the scenes, Azure runs the query periodically and evaluates the condition. If triggered, it fires the action group. Alerts can be enabled/disabled and have severity levels (0-4). Cost is based on the number of log queries evaluated (pay per query). This step transforms raw logs into proactive notifications.
Manage Retention and Archiving
By default, data is retained for 31 days. To change retention for a specific table, go to the workspace's 'Tables' menu, select a table, and adjust the retention period (up to 730 days). For longer retention, enable 'Long-Term Retention' (archive) which moves data to Azure Storage after the retention period ends. Archived data is cheaper to store but must be restored before querying. To restore, use the 'Restore' option in the portal, which creates a temporary table. You can also set a daily cap to limit data ingestion and avoid surprise costs. The cap stops ingestion when reached (but data before the cap is still queryable). Retention management is critical for compliance and cost control.
Scenario 1: Centralized Monitoring for a Multi-Tier Application
A financial services company runs a multi-tier application on Azure: web servers, app servers, and SQL databases. Each tier generates logs (IIS logs, application logs, SQL Server error logs). Without a centralized logging solution, troubleshooting a user-reported error requires checking logs on each server manually—a time-consuming process. The team creates a Log Analytics workspace and configures diagnostic settings for all resources. They install the Azure Monitor Agent on each VM with a data collection rule to collect IIS logs, Windows Event Logs, and performance counters. All data flows into the workspace. When an error occurs, an engineer writes a KQL query to correlate timestamps across tiers: union AppLogs, IISLogs, SQLErrors | where TimeGenerated > ago(1h) | where Severity == "Error". This reveals the root cause in minutes. Cost is moderate: ingesting ~10 GB/day from 50 servers costs around $300/month. The team sets a daily cap of 15 GB to avoid overage. They configure 90-day retention for compliance. Without this setup, troubleshooting would take hours and require multiple RDP sessions.
Scenario 2: Security Auditing for Compliance
A healthcare organization must comply with HIPAA, which requires logging all access to patient data. They enable Azure Activity Log and Azure AD audit logs to be streamed to a Log Analytics workspace. They also enable diagnostic settings for their Azure SQL databases to log all queries. The security team creates a KQL query that detects access from unusual IP addresses: AzureActivity | where CallerIpAddress not in (known_ips) | where OperationName contains "write". They set up a log alert that emails the security team whenever such an event occurs. Additionally, they archive logs to Azure Storage for 7 years to meet retention requirements. The workspace is configured with a retention of 365 days for hot data, then long-term archive. The cost for archiving is low (~$0.01/GB/month). In a real incident, this setup helped them identify a compromised account within minutes. If misconfigured (e.g., missing diagnostic settings for SQL), they would have no audit trail, risking non-compliance fines.
Scenario 3: Capacity Planning for a Growing SaaS Platform
A SaaS startup expects rapid growth and needs to track resource utilization to plan capacity. They collect performance counters (CPU, memory, disk IO) from all VMs into a Log Analytics workspace. They use a query to calculate average CPU usage per VM over the last 30 days: Perf | where CounterName == "% Processor Time" | summarize avg(CounterValue) by Computer, bin(TimeGenerated, 1d). This data is exported to Power BI to create dashboards for the operations team. They notice that three VMs consistently run at 90% CPU, indicating they need to be scaled up. They also use the workspace to monitor Azure SQL DTU consumption. The cost is about $500/month for 50 GB/day ingestion. They set up a budget alert in Azure Cost Management to notify if costs exceed a threshold. Without this, they might over-provision resources or miss performance degradation. Common mistakes include not filtering out verbose logs (e.g., debug logs) that inflate ingestion costs.
What AZ-900 Tests on This Objective
Objective 3.3: Describe the benefits and usage of Azure Monitor, including Log Analytics and alerts. The exam focuses on conceptual understanding, not deep KQL. You need to know:
What a Log Analytics workspace is (a centralized repository for log data).
How data is ingested (via agents, diagnostic settings, APIs).
The role of KQL for querying logs (you don't need to write queries, but you should recognize that KQL is the query language).
How Log Analytics integrates with Azure Monitor (Log Analytics is the data store, Azure Monitor is the overarching service).
Common use cases: troubleshooting, monitoring, security auditing.
Pricing model: pay for data ingested and retention beyond 31 days.
Most Common Wrong Answers and Why Candidates Choose Them
"Log Analytics stores metrics, not logs." This is false. Azure Monitor stores metrics separately in a time-series database. Log Analytics stores logs (event records). Candidates confuse the two because both are part of Azure Monitor. Remember: Metrics are numbers, logs are events.
"You need to provision a VM to run Log Analytics." False. Log Analytics is a fully managed PaaS service. No VMs are needed. Some candidates think of on-premises log managers that require servers.
"Log Analytics can only collect data from Azure resources." False. It can collect from on-premises and other clouds via agents. Candidates often assume Azure services only work with Azure resources.
"Kusto Query Language is the same as SQL." False. KQL is similar but distinct. Candidates with SQL background may assume they are identical. The exam may ask which language is used for Log Analytics queries—answer is KQL.
Specific Terms and Values That Appear Verbatim
Log Analytics workspace: The container for log data.
Kusto Query Language (KQL): The query language.
Azure Monitor Agent (AMA): The newer agent for data collection.
Data collection rules (DCRs): Define what data to collect.
Retention: Default 31 days, can be extended to 730 days.
Diagnostic settings: Configuration to send logs from Azure resources to Log Analytics.
Edge Cases and Tricky Distinctions
Log Analytics vs. Azure Monitor: Azure Monitor is the umbrella service that includes metrics, logs, and alerts. Log Analytics is the component that stores and queries logs. The exam may ask which service provides centralized log storage—answer is Log Analytics (within Azure Monitor).
Log Analytics vs. Application Insights: Application Insights is for application performance monitoring (APM) and uses Log Analytics as its data store. Application Insights data appears in a Log Analytics workspace but is accessed via the Application Insights blade. The exam may test that Application Insights uses Log Analytics for storage.
Data retention vs. archiving: Retention is for data kept in the workspace for querying. Archiving is for long-term storage in Azure Storage. Archived data cannot be queried directly without restoration.
Memory Trick or Decision Tree
For exam questions about where to store logs: if the question mentions "centralized log storage", "query logs using KQL", or "troubleshoot issues across resources", the answer is Log Analytics workspace. If it mentions "numerical values over time" or "performance counters", it's metrics (Azure Monitor Metrics). Decision tree:
Is it an event log? → Log Analytics.
Is it a metric (CPU, memory)? → Could be either, but metrics are stored in Azure Monitor Metrics, logs in Log Analytics. The exam often specifies "log data" vs. "metric data".
Is it about application performance? → Application Insights (which uses Log Analytics).
Remember: "Logs go to Log Analytics, metrics go to Metrics."
A Log Analytics workspace is a centralized repository for log data from Azure, on-premises, and other clouds.
Data is ingested via agents (Azure Monitor Agent), diagnostic settings, and APIs.
Logs are queried using Kusto Query Language (KQL) — you must know this for the exam.
Default data retention is 31 days; you can extend to 730 days (2 years) for a fee.
Log Analytics is part of Azure Monitor, not a separate service.
Pricing is based on data ingestion volume (per GB) and retention beyond 31 days.
Alerts can be created from log queries to trigger actions like email or automation.
The Azure Monitor Agent (AMA) replaces the legacy Log Analytics agent and uses data collection rules (DCRs).
Archiving to Azure Storage allows long-term retention (up to 7 years) but requires restoration before querying.
Log Analytics workspaces are region-specific; choose a region close to your resources to minimize latency.
These come up on the exam all the time. Here's how to tell them apart.
Azure Monitor Metrics
Stores numerical time-series data (e.g., CPU percentage, memory usage).
Data is stored in a lightweight time-series database with 93 days of retention (free) and up to 730 days (paid).
Queried using the Metrics Explorer with simple aggregation (average, min, max).
Best for real-time monitoring and dashboards of performance counters.
No query language required; you select metrics and apply filters.
Azure Log Analytics
Stores log event data (e.g., error messages, audit logs, custom logs).
Data is stored in tables within a Log Analytics workspace with 31 days default retention (up to 730 days).
Queried using Kusto Query Language (KQL) for complex filtering and aggregation.
Best for troubleshooting, security auditing, and custom log analysis.
Requires writing KQL queries to extract insights.
Mistake
Log Analytics workspaces can only be created in the same region as the resources being monitored.
Correct
Workspaces can be in any region, regardless of where resources are located. However, data may travel across regions, incurring egress costs and latency. Best practice is to place the workspace close to your resources.
Mistake
You must use the legacy Log Analytics agent for all data collection.
Correct
The legacy agent is being deprecated. The recommended agent is the Azure Monitor Agent (AMA), which supports both Windows and Linux and uses data collection rules for easier management.
Mistake
Log Analytics stores data indefinitely by default.
Correct
Default retention is 31 days. You can extend up to 730 days for an extra cost. Beyond that, you must archive to Azure Storage.
Mistake
You can query archived data directly from Log Analytics.
Correct
Archived data is stored in Azure Storage and must be restored to the workspace before querying. Restoring creates a temporary table that you can query for up to 30 days.
Mistake
Log Analytics is a separate service from Azure Monitor.
Correct
Log Analytics is a part of Azure Monitor. In the Azure portal, you access it via the Azure Monitor service. It is not a standalone service.
Azure Monitor is the overarching service for monitoring Azure resources. It includes metrics, logs, and alerts. Log Analytics is the component that stores and queries log data. Think of Azure Monitor as the umbrella, and Log Analytics as the log database within it. On the exam, if a question asks about centralized log storage, the answer is Log Analytics (which is part of Azure Monitor).
Install the Azure Monitor Agent (AMA) on the VM. Then create a data collection rule (DCR) that specifies which logs and performance counters to collect, and associate it with the Log Analytics workspace. Alternatively, you can enable diagnostic settings on the VM (legacy method). The AMA is the recommended approach for new deployments.
Yes. Install the Azure Monitor Agent (AMA) on your on-premises Windows or Linux servers. The agent will send data to your Log Analytics workspace over the internet (or via ExpressRoute for private connectivity). This allows you to centralize logs from hybrid environments.
You pay for the volume of data ingested (in GB) and for data retention beyond the first 31 days. There is no charge for the workspace itself. Commitment tiers (100 GB/day, 500 GB/day, etc.) offer discounts. Archiving to Azure Storage is cheaper but incurs storage costs. You can also set a daily cap to limit costs.
Default retention is 31 days. You can configure up to 730 days (2 years) for an additional cost. For longer retention (up to 7 years), you can archive data to Azure Storage. Archived data must be restored to the workspace before querying.
KQL is the read-only query language used to query log data in Log Analytics. It is similar to SQL but optimized for time-series and large datasets. You don't need to write KQL for the AZ-900 exam, but you should know that KQL is the language used to query logs. The exam may ask which language is used for Log Analytics queries.
Yes, you can create multiple workspaces, typically to separate environments (dev, test, prod) or for different business units. Each workspace has its own data, configuration, and access permissions. However, having too many workspaces can complicate cross-workspace queries.
You've just covered Azure Log Analytics and Workspaces — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?