Log Analytics
Log Analytics is the log store and query engine inside Azure Monitor — a workspace that ingests structured log and telemetry data and is queried with KQL. It is where platform logs, application telemetry, and security signals collect and where you investigate by querying across all of them together.
It is also where monitoring cost concentrates. Billing follows ingestion and retention, so the workspace design — what you collect, which data tier it lands in, how long you keep it — decides the bill as much as the value. The same workspace underpins Microsoft Sentinel, so these decisions cut across observability and security alike.
The Workspace
A Log Analytics workspace is the container and boundary for log data, access control, and retention. How many workspaces to run — one central or several per team or region — is an architectural choice: centralizing eases cross-resource queries and correlation, while splitting aids isolation and data-residency. Most estates settle on a small number of deliberately scoped workspaces rather than one per resource.
KQL
Kusto Query Language is the read-only language for querying logs — filter, aggregate, join, and visualize across tables. It is the same language used by Sentinel, Application Insights, and Resource Graph, so the skill transfers across the platform. A working command of KQL is the difference between logs as an expensive archive and logs as a live investigation tool.
Tables and Data Tiers
Data lands in typed tables, and each table can use a tier matched to its value. The Analytics tier supports full querying and alerting; the Basic and Auxiliary tiers ingest high-volume, low-value data far more cheaply for occasional search, with limits on querying and alerting. Putting verbose, rarely queried logs in a cheaper tier is the main lever on ingestion cost.
| Tier | Cost | Use for |
|---|---|---|
| Analytics | Highest | Data you alert on and query often |
| Basic / Auxiliary | Lower | High-volume, low-value, search-only logs |
Retention and Cost
Each table has an interactive retention period and an optional cheaper long-term archive. Retention beyond what you query is paid storage of data nobody reads; archive tiers keep compliance data affordably without inflating the active store. Because ingestion and retention drive the bill, the first design question for any data source is whether it earns its place and at which tier and retention.
- Ingesting everything into the Analytics tier when high-volume, low-value logs belong in Basic or Auxiliary tiers.
- Setting retention far longer than anyone queries, paying to store data that is never read.
- Spinning up a workspace per resource, fragmenting data and making cross-resource KQL queries impossible.
- Treating logs as a write-only archive because no one on the team can write KQL.
- Ignoring the cost impact of a chatty data source until the ingestion bill arrives.
- Forgetting that the same workspace also feeds Sentinel, so security and observability cost decisions are entangled.
- Design a small number of deliberately scoped workspaces, not one per resource.
- Tier data by value — Analytics for what you query and alert on, Basic/Auxiliary for high-volume search-only logs.
- Set interactive retention to query needs and archive compliance data to the cheaper long-term tier.
- Build KQL fluency on the team so logs are an investigation tool, not an archive.
- Evaluate each data source's ingestion cost against its value before connecting it.
- Coordinate workspace design with Sentinel, since it shares the same store and billing.
Knowledge Check
What primarily drives Log Analytics cost?
- Data ingestion and retention volume
- The number of KQL queries run
- The number of workspaces created
- The number of dashboards built on it
Where should high-volume, low-value, rarely queried logs go to control cost?
- The Basic or Auxiliary tier, which ingests cheaply with limited querying
- The standard Analytics tier, the very same place where all other logs are kept
- A longer retention period configured on the Analytics tier
- A dedicated separate workspace for each distinct log type
Why is KQL fluency important for Log Analytics?
- It is the read-only query language that turns stored logs into live investigation, and it transfers to Sentinel and App Insights
- It is required to ingest the data and stream it into the workspace tables in the first place, before any of it can ever be stored
- It reduces the per-gigabyte ingestion price you are billed for the data you store
- It is the only supported way to set a workspace's per-table retention period
You got correct