Nordlicht Reisen GmbH, a fictional travel agency, sends the logs of its storage accounts to a workspace (lesson 5.1). Now the auditors ask: "How many write operations were there yesterday, and how many of them failed?" The answer is not in a chart, it is in tables, and you fetch it with a query. The exam calls it query and analyze logs in Azure Monitor.

Prior knowledge. K3 teaches the language KQL (Kusto Query Language) in depth as a craft for application telemetry: K3, lesson 3.4.4 (KQL: asking the telemetry questions) with Application Insights, sampling, joins, and queries as files. This lesson does not repeat that. Here it is about operations: the workspace, its pricing tiers, retention, and costs, the query in the portal and on the command line, and as much KQL as the administration tasks need. The diagnostic settings that fill the workspace are in lesson 5.1, alerts from queries in lesson 5.3.

The workspace

A Log Analytics workspace is the store for Azure Monitor's log data. It contains tables; each table has columns and rows. The data comes from resources' diagnostic settings, from the activity log, from agents on machines, and from applications. Typical tables:

Table Content
AzureActivity the activity log, if you send it to the workspace at the subscription level
AzureDiagnostics resource logs in the collective format (older mode)
StorageBlobLogs blob logs of a storage account (resource-specific)
AzureMetrics metrics sent in through a diagnostic setting
Heartbeat, Perf heartbeats and performance counters from machines with an agent
Operation events of the workspace itself, including reaching the daily cap
Usage the amount of data ingested per table

Which tables and columns exist is shown by the Tables tab in the query editor.

Table plans

Every table has a plan:

  • Analytics: full feature set, queries, alerts; the normal case.
  • Basic: cheaper to store, restricted queries; queryable for a fixed 30 days.
  • Auxiliary: cheaper still for rare access, not usable for alerts.

A table can switch plans only once per week, and not every table supports all plans. If you only want to keep data, take Basic or Auxiliary; if you need alerts on the table, stay with Analytics.

Retention

  • Default: 30 days for tables with the Analytics plan (some tables have 90 days). You raise the value up to two years (730 days). 31 days are included in the ingestion price; a shorter value saves nothing.
  • Total retention: After that, the data stays in the table as long-term retention and can be retrieved through search jobs, up to 12 years in total. The command az monitor log-analytics workspace table update takes --total-retention-time up to 2556 days; for more, use the portal.
  • The default value applies to the workspace (portal: Usage and estimated costs → Data Retention), but can differ per table (Tables → Manage table).
PowerShell
az monitor log-analytics workspace update --resource-group <gruppe> `
  --workspace-name <arbeitsbereich> --retention-time 60
az monitor log-analytics workspace table update --resource-group <gruppe> `
  --workspace-name <arbeitsbereich> --name AzureActivity `
  --retention-time 90 --total-retention-time 365

Price, daily cap, access

What is billed is the amount of data ingested. According to the CLI reference, the default tier is PerGB2018; there are also tiers with reserved capacity (CapacityReservation). A daily cap ends the ingestion of billable data for the rest of 24 hours once it is reached; an event in the Operation table shows it. Microsoft warns: it is a protection against outliers, not a tool for saving money, because afterward you are blind for alerts and monitoring. An alert before the cap is better. To set it: portal Usage and estimated costs → Daily Cap, or --quota <GB-per-day> with az monitor log-analytics workspace create and update.

You grant access with Azure RBAC (lesson 1.3): the built-in role Log Analytics Reader allows reading and querying, Log Analytics Contributor additionally managing. The workspace is a resource like any other and lives in a resource group.