A Log Analytics workspace is the managed storage and search engine behind Azure Monitor Logs.

First, What Is a Log?

A log is a record of something that happened. When a web server answers a visitor, it can write a log entry saying who asked, what they asked for, and whether it worked. When someone signs in, changes a setting, or deletes a resource, a log entry can record that too. Logs are the diary of your systems. They are the first place engineers look when something breaks, slows down, or behaves strangely.

A single application may produce millions of entries a day. Reading them one at a time is impossible, so you need a tool that can store them all and answer questions quickly.

The Short Definition

A Log Analytics workspace is a cloud container in Azure where log data is collected and kept so it can be searched and analyzed. “Managed” means Microsoft runs the storage, the servers, and the search engine, so you do not install or maintain databases. You decide what data flows in, who can see it, how long it is kept, and what alerts or reports to build on top of it.

Workspaces are the data store for several Azure services. Azure Monitor uses them for logs, Microsoft Sentinel (the security monitoring service) is built on them, Microsoft Defender for Cloud can send data to them, and Application Insights can store its telemetry in them. Because many services share the same store, you can look at data from all of them side by side.

Modern systems are spread across many machines and services, so their diaries must be gathered in one place to make sense.

Life Without Central Logging

Picture an online shop. A customer clicks “Pay now,” and nothing happens. The cause might be in the website, the payment service, the database, the network, or a recent configuration change. If each part keeps its own log on its own machine, an engineer must log into each machine, find the right file, and read it, hoping the clocks match. By the time the answer is found, customers have given up.

The problem grows with scale. Cloud applications may run on dozens of virtual machines, containers that appear and disappear within minutes, and managed services that offer no machine to log into at all. Local log files vanish when a container is removed. Central logging solves this by sending entries to a safe, shared place the moment they are produced.

What You Gain

Six simple ideas explain almost everything: workspace, table, record, data source, query, and retention.

Workspace

The workspace is the container. It lives in one Azure region within one subscription (the billing account in Azure) and one resource group (a folder-like group for related resources). The workspace holds your data, your access settings, your retention choices, and your connections to other services.

Table

Inside a workspace, data is organized into tables, much like tabs in a spreadsheet. Each table holds one kind of record. There might be a table for heartbeat signals from virtual machines, a table for performance numbers, a table for security events, a table for Azure activity, and a table for web requests. Many tables come ready-made for Azure services, and you can create custom tables for your own data.

Record

Each row in a table is a record, one logged event. Records have columns, such as the time the event happened, the computer that produced it, a severity level, and a message. Every record has a timestamp, which is essential because most questions are about “what happened and when.”

Data Source

A data source is anything that sends records into the workspace. Examples include Azure resources, virtual machines, Kubernetes clusters, applications, on-premises servers, and security services. Later chapters explain how each one connects.

Query

A query is a question you ask of the data. Log Analytics uses a language called Kusto Query Language, often shortened to KQL. It reads like a pipeline: start with a table, filter it, group it, count it, and sort it, passing results from one step to the next, like items moving along a conveyor belt through inspection stations.

Retention

Retention is how long data is kept before it is removed. You can choose different periods for different tables, balancing usefulness against cost.

flowchart TD
  S1["Azure resources"] --> W["Log Analytics workspace"]
  S2["Virtual machines and servers"] --> W
  S3["Containers and Kubernetes"] --> W
  S4["Applications"] --> W
  W --> T1["Table: performance data"]
  W --> T2["Table: security events"]
  W --> T3["Table: activity records"]
  W --> T4["Table: custom data"]
  T1 --> Q["Queries, alerts, workbooks"]
  T2 --> Q
  T3 --> Q
  T4 --> Q
        

Different sources use different paths, but all of them end up as records in tables.

Path One: Diagnostic Settings for Azure Resources

Most Azure services, such as databases, storage accounts, and firewalls, can send their logs and metrics to a workspace through a setting called a diagnostic setting. You choose the resource, pick which categories of logs to send, and pick the destination workspace. No software has to be installed because the service itself does the sending. The same diagnostic setting can also send data to a storage account for cheap archiving or to an event stream for other systems.

Path Two: Agents on Machines

Virtual machines and servers, whether in Azure, in another cloud, or in your own data center, need a small helper program called an agent to collect their local logs and performance numbers. The modern agent is the Azure Monitor Agent. It replaced older agents, including the earlier Log Analytics agent, which Microsoft has retired. Machines outside Azure first connect to Azure through a service called Azure Arc so they can be managed like Azure machines.

Path Three: Data Collection Rules

A data collection rule is a set of instructions that says what to collect, how to shape it on the way in, and where to send it. You attach a rule to machines or resources, and they follow it. This is much tidier than configuring every machine by hand. Rules can also filter or transform data before it is stored, such as dropping noisy records or removing sensitive fields, which saves money and protects privacy.

Path Four: Application Telemetry

Applications can send traces, errors, and request information through Application Insights, which can store its data in a workspace. This lets developers and operators search application behavior and infrastructure behavior together.

Path Five: Custom Sources

For anything else, such as logs from a business application or a partner system, a Logs Ingestion interface allows programs to send data into a custom table, guided by a data collection rule. This is useful for bringing in data that Azure does not collect on its own.

Following one record from creation to search shows where each setting and cost fits in.

The Journey in Plain Words

Suppose a web server records that a customer’s payment request failed. The agent on that server notices the new entry. Following its data collection rule, it packages the entry, adds the machine name, and sends it securely over the network to the workspace. On arrival, the service may apply a transformation that trims unneeded fields. The record is then placed into the right table and indexed so it can be found quickly. Within a short time, usually minutes at most, it becomes searchable. An alert rule that watches for payment failures notices a spike and sends a message to the on-call engineer.

sequenceDiagram
  participant S as Web Server
  participant A as Azure Monitor Agent
  participant R as Data Collection Rule
  participant W as Log Analytics Workspace
  participant L as Alert Rule
  participant E as On-Call Engineer
  S->>A: Writes a failed payment entry
  A->>R: Checks what to collect and where to send
  R->>A: Collect this entry, send to workspace
  A->>W: Sends the record securely
  W->>W: Applies transformation and stores in table
  L->>W: Runs scheduled query for payment failures
  W->>L: Returns a spike in failures
  L->>E: Sends notification
        

Ingestion Delay

Logs are not instant. There is a small delay between an event happening and it becoming searchable, caused by collection, transmission, and indexing. For most purposes this delay is short, but it matters when you design alerts. An alert that checks data from the last minute may miss events that have not arrived yet, so alerts usually look at slightly older time windows to allow for late arrivals.

KQL is how you ask questions, and it is easier to learn than it looks because it reads like a recipe.

Thinking in Pipelines

A KQL query starts with the name of a table and then passes the rows through a series of steps. Each step does one small job. One step keeps only rows from the last hour. The next keeps only rows where the severity is an error. The next counts rows per computer. The last sorts the counts from highest to lowest. You can read it from top to bottom as a plain-language instruction, which is why many people find it friendly.

The Kinds of Questions You Can Ask

Habits for Fast, Cheap Queries

The workspace handles large volumes well, but careless queries can be slow. Good habits make a large difference. Always limit the time range first, because scanning a day is far cheaper than scanning a year. Filter early, so later steps work on fewer rows. Choose only the columns you need rather than every column. And prefer simple, exact comparisons over complicated text searching across entire records when you can.

Not all logs are equally valuable, so Azure lets you store different tables at different levels of capability and cost.

Why Plans Exist

Some logs are checked every day by engineers and drive alerts. Others are huge, noisy, and only rarely needed, such as detailed network flow records kept for investigations. Paying premium prices to store both the same way would waste money. Table plans let you match the storage style to the value of the data.

How long you keep data is both a compliance question and a cost question.

Two Stages of Keeping Data

Data in a workspace moves through two stages. In the first, called interactive retention, data is fully searchable and ready for fast queries. By default, workspaces keep data in this stage for a modest period, often thirty days, and you can extend it. In the second stage, called long-term retention or archive, data costs much less to keep but cannot be queried in the usual quick way. When you need archived data, you run a special search job or restore a slice of it back into a searchable state for a while.

You can set retention for the whole workspace and override it for individual tables. This is powerful: security audit logs might be kept for years, while chatty debug logs are kept for a week.

Choosing Retention Periods

Exporting and Summarizing

Besides retention inside the workspace, you can continuously export data to a storage account for very cheap long-term keeping, or to an event stream so other systems can process it. Another helpful feature is the summary rule, which regularly condenses large raw data into small summary tables, such as hourly counts, so you can keep the summary for years while discarding the raw detail sooner.

Logs often contain sensitive details, so access must be carefully controlled.

Why Logs Are Sensitive

Logs can contain usernames, network addresses, error messages with internal details, and sometimes accidentally even personal data. Anyone who can read logs can learn a great deal about your systems. Access should therefore follow the principle of least privilege: each person gets only the access they need.

Azure Roles for Logs

Azure uses role-based access control. You assign roles to people or groups, and the roles decide what they may do. Common roles for workspaces include a reader role that allows running queries, a contributor role that also allows managing settings and data sources, and more specific roles such as ones that allow sending monitoring data only. Granting roles to groups instead of individuals makes team changes much simpler.

Two Ways to Access Data

There are two access modes. In workspace-context access, a person is given access to the workspace itself and can see the tables they are permitted to see. In resource-context access, a person who has access to an Azure resource, such as a particular virtual machine, can see only the log records produced by that resource, even without access to the whole workspace. This is ideal for application teams who should see their own logs but not those of other teams.

Finer Control

Azure also supports permissions at the table level, so a person can be allowed to read some tables but not others. This helps when one workspace contains both everyday operational logs and highly sensitive security logs.

One workspace or many? The answer depends on a handful of practical factors.

The Big Question

Organizations often ask how many workspaces to create. A single workspace is simple: all data is in one place, and queries need no special effort to combine sources. But reasons to split exist, and the best designs balance simplicity against real requirements. Microsoft’s general guidance leans toward fewer workspaces when possible, adding more only when a clear reason applies.

Reasons to Use More Than One Workspace

Querying Across Workspaces

If you do have several workspaces, queries can look across them. This is handy but comes with costs: cross-workspace queries can be slower, and people need permission on each workspace involved. Keeping most related data together reduces the need for this.

flowchart TD
  A["Do rules force data to stay in a specific region?"] -->|Yes| B["Create a workspace in that region"]
  A -->|No| C["Does data need strict isolation from other teams?"]
  C -->|Yes| D["Use a separate workspace or table-level permissions"]
  C -->|No| E["Do you have more than one tenant?"]
  E -->|Yes| F["Create a workspace per tenant"]
  E -->|No| G["Start with one central workspace"]
        

Alert rules turn a stored question into a standing guard that notifies you when something changes.

How Log Alerts Work

A log search alert rule runs a query on a schedule, such as every five minutes. If the result meets a condition you defined, such as “more than twenty failed payments in the last ten minutes,” the rule fires an alert. The alert can notify people by email, text message, or phone call, post to a chat tool, open a ticket in a service desk system, or trigger an automated response. The notification targets are bundled into a reusable group called an action group.

Types of Alert Conditions

Designing Alerts People Trust

The greatest danger with alerts is noise. If people receive dozens of unimportant alerts, they stop paying attention, and the one important alert gets lost. Good alerts are actionable, meaning someone knows what to do when they fire. They use sensible time windows to allow for ingestion delay, and they have clear names and descriptions explaining what is wrong and where to start looking.

Queries answer questions; visuals help whole teams see the answer at a glance.

Workbooks

A workbook is an interactive report built from queries. It can combine text, charts, tables, and filters in one page, such as a drop-down that lets a viewer choose a time range or a specific server. Workbooks are excellent for health reviews, incident summaries, and security overviews, because they tell a story with live data rather than a static screenshot.

Dashboards

Azure dashboards let you pin charts and tiles from queries onto a shared board for an at-a-glance view, much like the instrument panel of a car. Teams often keep one on a large screen showing the health of important systems.

Ready-Made Insights

Azure offers ready-made experiences that sit on top of workspace data, including monitoring views for virtual machines, containers, and networks. They collect specific data and display it in friendly, pre-built screens so you gain value without writing queries yourself.

A workspace holds valuable information, so the workspace itself must be protected.

Protecting Data in Motion and at Rest

Data sent to a workspace travels over encrypted connections, and data stored in the workspace is encrypted at rest by default using keys managed by Microsoft. Organizations with stricter rules can bring their own encryption keys, usually through a dedicated cluster option, so that they control the keys used to protect their logs.

Private Connectivity

By default, workspaces can be reached over the public internet, protected by authentication. For sensitive environments, organizations can use Azure Private Link with an Azure Monitor private link scope so that data flows between their network and the workspace without crossing the public internet, and public access can be turned off.

Keeping Sensitive Data Out of Logs

The safest sensitive data is data that never enters the log. Developers should avoid writing passwords, access tokens, or full personal details into logs. When unwanted data does slip in, transformations in data collection rules can remove or mask it before storage. Table-level access and shorter retention for risky tables add further protection.

The main cost of a workspace comes from how much data you send in, so cost control starts at the front door.

What You Pay For

The main driver is data ingestion, billed by the volume of data stored, typically measured in gigabytes. There are also charges for keeping data beyond the included retention period, for archived data, for running searches on archived data, and for certain features such as exporting data. Prices differ by region and change over time, so always check the current pricing page.

Pricing Models

Practical Ways to Reduce Cost

The Daily Cap

A workspace can have a daily cap, a limit on how much data may be collected in a day. When the cap is reached, collection of most data stops until the next day. This protects your budget, but it also means you may lose important logs, including security data, during exactly the kind of incident that creates a flood of events. Many teams use a cap carefully, if at all, and rely on usage alerts instead.

No technology is perfect. Seeing both sides helps you decide where a workspace fits.

Comparing Ways to Keep Logs

Teams repeat the same successes and the same mistakes. Learn from both.

Patterns Worth Copying

Anti-Patterns to Avoid

Across industries, teams use workspaces to keep systems healthy, secure, and accountable.

A short checklist that captures the lessons from earlier chapters.

Best Practices

Common Mistakes

You can begin with a few simple steps and grow from there.

Not exactly. Azure Monitor is the overall monitoring service. A Log Analytics workspace is the place where Azure Monitor Logs data is stored and queried. Other tools, such as alerts and workbooks, use the workspace as their data source.

KQL is the Kusto Query Language used to search workspace data. You can get value from ready-made screens without it, but learning the basics greatly improves your ability to investigate problems and build alerts.

Through the Azure Monitor Agent, guided by a data collection rule that says what to collect and where to send it. Machines outside Azure usually connect through Azure Arc first.

No. Most Azure services send logs through diagnostic settings, which you configure on the resource, without installing any software.

By default workspaces keep data fully searchable for a modest period, and you can extend it and set different periods per table. Beyond that you can use long-term retention at lower cost. Confirm the current defaults and maximums in Microsoft’s documentation.

Almost always because of ingestion volume. A chatty log category, a misbehaving application, or too many machines sending detailed data can add up quickly. Review which tables are largest and filter or change plans for noisy data.

Start with one central workspace and add more only for clear needs, such as data residency in a specific region, separate tenants, or strict isolation of very sensitive data.

Yes. With resource-context access, a person who has access to an Azure resource can see the records from that resource without being given access to the whole workspace.

The Analytics plan offers full query and alert capability at a higher cost. The Basic plan costs less for high-volume data that you rarely need, but with more limited querying and a short interactive retention period.

Yes. Collection, transmission, and indexing take a short time, so logs are near-real-time, not instant. Design alerts with time windows that allow for this delay.

Use Azure Private Link with an Azure Monitor private link scope, and then restrict or disable public access to the workspace.

A daily cap protects your budget but can stop collection of important data, including during a security incident. Use it carefully, and pair it with alerts that warn you before the cap is reached.

A Log Analytics workspace is the managed home for the log data your cloud systems produce. Azure resources, virtual machines, containers, and applications send their records into tables, where you search them with Kusto Query Language, watch them with alert rules, and display them in workbooks and dashboards. Data collection rules and diagnostic settings control what flows in, table plans and retention control how it is stored, and roles and private connectivity control who can see it and how it travels.

Success comes from keeping the design simple, collecting what you will actually use, matching storage to the value of each table, controlling access carefully, and watching your own usage and cost. A well-run workspace quietly turns thousands of scattered notes into clear answers.