Azure Log Analytics workspaces are the central repository for log and performance data from your Azure and on-premises environments. Think of it as a highly scalable, managed time-series database specifically designed for operational telemetry.
Here’s a simplified view of how it works in practice. Imagine you have a web application running on Azure App Service, and you want to collect its request logs and performance metrics.
First, you create the workspace itself. This is a resource within your Azure subscription.
az monitor log-analytics workspace create --resource-group MyResourceGroup --workspace-name MyLogAnalyticsWorkspace
This command creates the workspace and assigns it a unique Workspace ID. You’ll need this ID later.
Next, you configure your Azure resources to send data to this workspace. For our App Service example, you’d enable diagnostic settings.
Go to your App Service resource in the Azure portal, navigate to "Diagnostic settings," and click "Add diagnostic setting." You’ll select the log categories you’re interested in (e.g., AppServiceHTTPLogs, AppServiceAppLogs, AppServicePlatformLogs) and metrics (e.g., AppServiceEnvironmentMetrics, Http5xx). Then, you choose "Send to Log Analytics workspace" and select the MyLogAnalyticsWorkspace you created.
{
"logs": [
{
"category": "AppServiceHTTPLogs",
"enabled": true,
"retentionPolicy": {
"days": 30,
"enabled": true
}
},
{
"category": "AppServiceAppLogs",
"enabled": true,
"retentionPolicy": {
"days": 30,
"enabled": true
}
}
// ... other log categories
],
"metrics": [
{
"category": "AllMetrics",
"enabled": true,
"retentionPolicy": {
"days": 30,
"enabled": true
}
}
],
"workspaceId": "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/MyResourceGroup/providers/Microsoft.OperationalInsights/workspaces/MyLogAnalyticsWorkspace"
}
Once configured, your App Service starts streaming its logs and metrics to MyLogAnalyticsWorkspace. You can then query this data using Kusto Query Language (KQL) directly in the Azure portal’s "Logs" section. For instance, to see HTTP status codes from your App Service:
AppServiceHTTPLogs
| where TimeGenerated > ago(1h)
| summarize count() by HttpStatus
This query looks at the AppServiceHTTPLogs table, filters for logs generated in the last hour, and then counts the occurrences of each HttpStatus. The output would be a table showing counts for 200s, 404s, 500s, etc.
The primary problem Log Analytics workspaces solve is the aggregation and analysis of diverse operational data at scale. Before Log Analytics, you might have had separate logging systems for each service, making cross-service correlation and performance analysis a nightmare. Log Analytics provides a unified, queryable source for all this telemetry.
Internally, Log Analytics workspaces leverage Azure Data Explorer technology. Data is ingested, indexed, and stored in a highly optimized columnar format, allowing for incredibly fast analytical queries over massive datasets. The workspace acts as the managed service layer, handling scaling, retention, and access control.
The exact levers you control are primarily around:
- Data Ingestion: Which resources send data, which specific logs and metrics are collected, and how frequently.
- Data Retention: How long data is kept in the workspace (e.g., 30 days, 90 days, 365 days). This impacts cost and compliance.
- Querying: Using KQL to extract insights, build dashboards, and set up alerts.
- Cost Management: Understanding the pricing model, which is largely based on data ingestion volume and retention period.
A common point of confusion is the distinction between "Logs" and "Metrics" in diagnostic settings. While both are sent to Log Analytics, "Logs" are typically event-based records (like individual HTTP requests, application errors, or system events), while "Metrics" are numerical time-series data points representing performance indicators (like CPU utilization, request duration, or memory usage). You can query both using KQL, but their origin and typical use cases differ.
Once you’ve got data flowing and are comfortable querying, the next logical step is to automate responses to patterns in that data, typically through Azure Monitor Alerts.