Before learning the tool, understand the problem it solves.

What a log is

A log is a time-stamped record that a system writes to describe something that happened: a user signed in, a disk filled up, a web request failed, a virtual machine was restarted. Each entry usually carries a time, a source, a severity, and a message. One entry is not interesting. Millions of entries, searched together, tell you what your systems actually did.

Why logs matter

Logs answer questions that nothing else can. Why did the website slow down at three in the morning? Who deleted that storage account? Did the attack reach other servers? Metrics, which are simple numbers sampled over time, tell you that something is wrong. Logs tell you why. In regulated industries, logs are also legal evidence that controls worked.

The three pillars of observability

The central collection problem

In a cloud estate, logs are born in hundreds of places: virtual machines, databases, firewalls, containers, identity systems. If every one keeps its own file, nobody can search across them, files vanish when machines are deleted, and attackers can erase their own traces. The answer is to send everything to one central, protected, searchable store. In Azure, that store is the Log Analytics workspace.

A workspace is the container where Azure Monitor stores log data and lets you query it.

Definition

A Log Analytics workspace is an Azure resource that holds log data in tables and provides the engine to search that data. It belongs to one subscription and one region. It has its own settings for retention, access, pricing, and network access. Think of it as a database built specially for log and event data, hosted and managed by Microsoft, which scales without any server for you to run.

Where it sits in Azure Monitor

Azure Monitor is the family name for Microsoft’s monitoring services. It has two main data stores. The metrics store keeps numbers. The logs store, which is the Log Analytics workspace, keeps records. Features such as log alerts, workbooks, Application Insights, VM insights, container insights, and Microsoft Sentinel all read from workspaces.

flowchart TD
  SRC["Sources: VMs, Azure services, apps, containers, custom feeds"] --> COL["Collection: agents, diagnostic settings, ingestion API"]
  COL --> WS["Log Analytics workspace: tables and retention"]
  WS --> Q["Log Analytics queries"]
  WS --> AL["Log alerts"]
  WS --> WB["Workbooks and dashboards"]
  WS --> SEN["Microsoft Sentinel"]
  WS --> EXP["Data export to storage or event hub"]
        

What it gives you

Regions, limits, and what a workspace is not

Each workspace sits in a single Azure region, chosen when it is created, and the data stays in that region unless you export it. A workspace is not a backup system and not a long-term document store. It is a query engine over events. It also does not replace metrics for fast numeric alerts, nor traces for following one request across services. Many mature estates use all three together, with the workspace as the place for investigation, audit, and deep analysis. Knowing what the workspace is for prevents the common mistake of forcing it to do every monitoring job.

A good guide must describe the service as it is now, including the changes that affect real estates.

Three table plans

Each table in a workspace now carries a plan that trades price against capability. Analytics is the full-featured plan for data you monitor and alert on. Basic offers reduced ingestion cost for data used for troubleshooting. Auxiliary, which Microsoft’s current documentation labels Auxiliary or Lake, offers the lowest ingestion cost for verbose and compliance data that is rarely queried. All three live in the same workspace. The plans are covered in depth later.

Older collection methods are retired

The HTTP Data Collector API, long used to push custom data, reached the end of support on 14 September 2026 according to Microsoft’s migration guidance, and its endpoint has refused older TLS versions since 1 March 2026. Its replacement is the Logs ingestion API, which sends data through data collection rules. The older Log Analytics agent, known as the Microsoft Monitoring Agent, has been replaced by the Azure Monitor Agent. Estates still using the old paths should migrate now.

Pricing and legacy tiers

Pay-as-you-go and commitment tiers are the modern pricing models. Commitment tiers start at one hundred gigabytes per day. Several legacy pricing tiers still exist only for old subscriptions and do not support the Basic and Auxiliary plans. A workspace on a legacy tier cannot use the cheaper plans, which is a strong reason to move it.

Understanding the path a log takes explains almost every setting you will meet.

The building blocks

Two ways data gets in

Some data is pulled by an agent running on a machine, which reads event files and counters and sends them on. Other data is pushed by Azure itself: when you enable a diagnostic setting on a resource, the platform streams its logs to the workspace with no agent. Custom applications and tools use the Logs ingestion API. All paths end at a table.

flowchart LR
  VM["Virtual machine"] --> AMA["Azure Monitor Agent"]
  AMA --> DCR["Data collection rule: filter and transform"]
  PAAS["Azure resource"] --> DS["Diagnostic setting"]
  APP["Custom application"] --> API["Logs ingestion API"]
  API --> DCR
  DS --> TBL
  DCR --> TBL["Workspace tables"]
  TBL --> USE["Queries, alerts, workbooks, Sentinel"]
        

Everything in a workspace lives in a table, and table choices drive cost and capability.

What a table is

A table is a collection of records that share the same set of columns. Each record is one event. Column types include text, numbers, true or false, date and time, dynamic data for flexible structures, and identifiers that are stored and queried as text. Table names are case sensitive, which surprises many beginners.

Kinds of tables

Standard columns

Every record also carries standard columns that Azure adds, such as the time it was generated, a billing flag, and the billed size of the record. The billing columns are useful, since they let you ask the workspace itself which tables and sources cost the most. Some tables, including activity records, heartbeat, usage, and operation tables, are free of ingestion charge, though you should confirm that with the billing flag instead of assuming.

Schema changes

You can add columns to custom tables. Changing a schema carelessly can break senders that still use older rules. For tables fed by the retired Data Collector API, adding columns through the portal or interface can break legacy ingestion, so plan the migration first. The new API does not adjust schemas automatically, so a source that adds a field must be matched by a table change, a transformation that drops the field, or a decision to leave that field uningested.

There are four main ways to feed a workspace, and each fits a different kind of source.

Azure Monitor Agent

The Azure Monitor Agent is installed on a machine and, instead of keeping its own configuration, receives instructions from one or more data collection rules associated with the machine. The same machine can follow several rules, one for security events, one for performance counters, and one for text logs. Because rules are separate Azure resources, you can apply one rule to a thousand machines through policy.

Diagnostic settings

Most Azure services produce platform logs and metrics. A diagnostic setting tells the service where to send them: a workspace, a storage account for cheap archival, or an event hub for streaming to other tools. Different settings can send different categories to different places. Many categories can be extremely noisy, so choose with care.

Logs ingestion API

For your own applications, the Logs ingestion API takes batches of records and sends them through a collection rule into a named table. It authenticates with an Entra identity instead of a shared key, which removes the old problem of a workspace key that can write anything. Each call is limited to about one megabyte, so large senders send several calls in parallel.

Planning a rollout wave by wave

Resist the urge to switch on collection everywhere in one afternoon. Start with the resources whose logs your security and operations teams already use, confirm that the data arrives and is useful, then expand to the next tier of importance. For each wave, record expected daily volume before and after, so you can compare plan against reality. Early waves teach you which categories are noisy, which collection rules need filtering, and which teams need training. Later waves then go quickly because the standard, the templates, and the policy are already proven.

Data collection rules are the control panel for what enters the workspace, and therefore for what you pay.

Anatomy of a rule

Why transformations matter

A transformation runs on the way in, before data is stored and billed. This is the most powerful cost control in the service, because dropped data costs nothing. It can remove noisy events, strip large unneeded columns, mask sensitive values such as account numbers, split one stream into several tables, or convert formats. It can also route low-value data to a table with a cheaper plan.

Rule design habits

Follow one record from creation to query to see where delay, cost, and failure come from.

Step one: creation and pickup

An event happens and the source writes it. The agent or the platform collects it, usually in small batches, and sends it over an encrypted connection. Collection is not instant. Batching and buffering add seconds or minutes.

Step two: the rule and transformation

The service receives the batch, matches it to the collection rule, runs the transformation, and checks that the result fits the destination table. Values that do not match the schema are dropped but may still be billed.

Step three: ingestion and storage

The records are written to the table. At this point they are billed by size. They are available in interactive retention, where queries are fast. A short ingestion latency, typically from seconds to a few minutes, separates event creation from visibility in queries.

Step four: use and aging

Queries, alerts, and workbooks read the data. After the interactive retention period, data moves to long-term retention at a reduced price, where it can still be reached by search jobs or restored for deeper analysis. When total retention ends, data is removed.

sequenceDiagram
  participant S as Source
  participant C as Agent or platform
  participant R as Collection rule
  participant W as Workspace table
  participant U as Query, alert, workbook
  S->>C: Event occurs
  C->>R: Send batch over encrypted channel
  R->>R: Filter and transform
  R->>W: Write records, bill by size
  W-->>U: Available for fast queries
  U->>W: Query by time range
  W->>W: After interactive retention move to long term
  U->>W: Search job or restore for old data
        

The query language is how you turn a mountain of records into answers. Its core ideas are simple.

The pipeline idea

A query starts with a table name and then passes the rows through a series of steps, each one refining the result. One step filters rows, another picks columns, another groups and counts, another sorts, another limits the output, and another draws a chart. Steps are chained one after another, like stations on an assembly line, and each station receives the output of the previous one.

Core operations in plain words

Habits that make queries fast

Learning the language step by step

A practical way to learn is to begin with a single table and ask one question at a time. First, show a few records to see the columns. Second, keep only the last hour. Third, keep only the rows of interest. Fourth, count them by a useful column. Fifth, draw the count over time. Each step builds on the one before, and mistakes are easy to spot because the result changes a little at a time. Within a few days, most people can answer their own everyday questions, and within weeks they are writing reusable functions that other teams adopt.

The portal offers several ways to ask questions, suited to different people and data ages.

Simple mode and KQL mode

The query interface has two modes. Simple mode lets someone with no query language knowledge pick tables, filter and sort with clicks, and explore results in a spreadsheet-like grid. KQL mode is for writing and editing queries that can be saved, shared, turned into alerts, or placed in workbooks. Beginners start in simple mode and graduate as needs grow.

Query scope

Basic and Auxiliary tables can only be queried at workspace scope, while Analytics tables support resource scope as well. This matters for application teams that rely on resource-centric access.

Search jobs and restore

Interactive queries are designed for quick answers on recent data. For very large or old data, two other tools exist. A search job runs asynchronously, scans a large range, and copies matching records into a new search results table, which you can then query quickly. A restore brings a chosen time range of a table back into fast storage temporarily, so heavy analysis can run as if the data were recent. Search jobs work on all three table plans. Restore is available on Analytics and Basic only.

Choosing the right tool for the question

A quick matching guide helps beginners. For recent events, ask an interactive query. For a repeating chart, build a workbook on a summary table. For one needle in last year’s haystack, run a search job. For a week of deep investigation across many questions about an old incident, restore the period and work on it. For an application owner who only needs their own system’s logs, use resource scope. Picking the right tool avoids both frustration and unexpected charges, because each tool has a different speed and a different price.

Choosing the plan for each table is the biggest single cost decision after choosing what to collect.

How to read the table

Analytics is the plan you reach for when someone will watch the data or write alerts on it. The ingestion price is highest, but queries cost nothing extra and the first thirty-one days of retention are included. Basic gives most of the query power for a lower ingestion price, but you pay per gigabyte scanned and give up some alerting and integrations. Auxiliary is the cheapest way to land large volumes and keep them for years, at the cost of slower queries and fewer features.

What qualifies for which plan

Not every table can use every plan. Basic and Auxiliary apply to Azure tables that Microsoft has enabled for them, and to custom tables created through data collection rules. Workspaces on legacy pricing tiers cannot use Basic or Auxiliary at all. Check the supported table list before planning savings.

A simple classification method

Keeping data longer is easy. Paying sensibly for it is the art.

Two stages of life

Data in an Analytics table first lives in interactive retention, where queries are fast and complete. The default is thirty days, with ninety days for workspaces used with Microsoft Sentinel and Application Insights data. You can extend interactive retention up to two years for a prorated fee beyond the included period. After that, data enters long-term retention, which is cheaper, and stays until the total retention period ends, up to twelve years. Basic and Auxiliary tables have no interactive stage and rely on total retention.

flowchart LR
  I["Ingestion"] --> H["Interactive retention: fast queries, default 30 days"]
  H --> L["Long term retention: cheaper, search jobs and restore"]
  L --> D["Deleted when total retention ends"]
  H -. restore .-> H2["Restored table for deep analysis"]
  L -. search job .-> S["Search results table"]
        

Setting retention

Retention is set at the workspace level as a default and can be overridden per table. A security table may be kept for seven years while a verbose performance table is kept for forty-five days. Retention is billed daily. Reducing retention lowers future cost, but remember that purging data does not reduce retention charges for data that remains, and deleting a custom table does not delete its data, so retention charges can continue until the data ages out.

Deciding how long

A worked retention example

Imagine three tables. A sign-in table feeds security alerts, so it stays in interactive retention for ninety days and in long-term retention until it reaches two years. A web server request table is used for troubleshooting only, so it sits on the Basic plan and is kept for forty-five days. A platform audit table exists purely to satisfy a regulator who may ask questions up to six years later, so it sits on the Auxiliary plan with total retention of six years. Each table has an owner, a reason, and a cost that matches its value. This is the target state: retention that reflects need, not habit.

Four tools help you get value from data without scanning everything every time.

Summary rules as a cost lever

Summary rules deserve special attention. Suppose a firewall produces billions of connection records, but the dashboard needs only counts per hour per rule. A summary rule writes those counts to a small table. The big table can then sit on a cheaper plan or shorter retention, while the dashboard stays fast and cheap. On Basic and Auxiliary tables, the summary query is limited to a single table.

Microsoft’s guidance is simple: begin with one workspace and add more only for a specific reason.

Reasons to create more than one

flowchart TD
  START["Start: one workspace"] --> Q1{"Multiple Entra tenants?"}
  Q1 -- Yes --> A1["One workspace per tenant"]
  Q1 -- No --> Q2{"Data residency rules by region?"}
  Q2 -- Yes --> A2["One workspace per required region"]
  Q2 -- No --> Q3{"Need different retention for same table or strict ownership split?"}
  Q3 -- Yes --> A3["Add workspaces for those groups"]
  Q3 -- No --> A4["Keep a single workspace"]
  A1 --> CL{"Combined 100 GB per day or more?"}
  A2 --> CL
  A3 --> CL
  A4 --> CL
  CL -- Yes --> DC["Consider dedicated cluster"]
  CL -- No --> OK["Stay on standard pricing"]
        

The money side of the decision

Combining data can unlock a commitment tier. In Microsoft’s own example, fifty gigabytes per day of operational data and fifty of security data separately miss the hundred gigabyte tier, but together they reach it, earning a discount on monitoring and a larger discount on Sentinel. Splitting by region can reduce bandwidth charges, yet those are often small compared with ingestion, and splitting may lose tier discounts. Duplicate data in several workspaces always adds cost.

Cross-workspace queries

Queries can span workspaces, which softens the downside of having several. Very wide queries over dozens of workspaces become slow, and there is an upper limit on how many workspaces one query can reach. Placing workspaces on a shared dedicated cluster reduces that problem.

Logs often contain personal data, security events, and secrets. Who can read them is a serious question.

Two access modes

The workspace setting can use resource or workspace permissions, which allows both models together, or require workspace permissions, which turns resource-context access off. Note that resource-context access depends on the resource being identifiable in the records, so some custom data without resource identifiers will not follow the rule.

Table-level access

Azure role-based access control can grant or deny access to individual tables. An audit team might receive only security tables, while an application team may be denied the security tables. Combine table-level rules with resource-context to build a layered model that follows least privilege.

Designing roles around real jobs

Built-in roles cover most needs, such as reader for querying and contributor for management, but some organizations create custom roles that allow only running queries without reading certain tables, or only managing alert rules. Pair roles with groups from the identity directory so that joining or leaving a team updates access automatically. Review assignments every quarter, remove stale ones, and use time-limited elevation for rare administrative work. Access to logs is access to knowledge about your whole estate, so it deserves the same discipline as access to production systems.

The workspace stores the evidence of everything else. Protecting it protects the whole investigation trail.

Encryption and protection

Data is encrypted in transit and at rest by default using keys managed by Microsoft. Organizations with stricter rules can use customer-managed keys, which require a dedicated cluster. With a customer-managed key, you hold the key in your own key vault and can revoke access, which makes the data unreadable. Customer Lockbox, available on Analytics and Basic tables, gives you approval control over Microsoft support access to your data in rare support cases.

Dedicated clusters

A dedicated cluster is a managed environment that hosts one or more workspaces and unlocks capabilities such as customer-managed keys and pooled commitment pricing. The minimum commitment is one hundred gigabytes per day, with no pay-as-you-go option. The commitment can be raised at any time but cannot be reduced during its thirty-one day period. Billing starts when the cluster is created, even if no workspace is linked, so do not create one early.

Protecting the data itself

Thinking like an attacker

Attackers often try to blind defenders before acting, for example by disabling agents, deleting diagnostic settings, or lowering retention. Protect against this by restricting who can change those settings, alerting on any change to collection or retention, and storing a second copy of critical logs in a location the same administrators cannot alter. Watching the watchers is a core security habit. Treat a sudden drop in logs from a sensitive system as a possible incident until proven otherwise, not merely as a technical glitch.

By default a workspace is reachable over the public internet with strong authentication. Many organizations want it reachable only from their private networks.

Private link scopes

Azure Monitor Private Link Scope, usually shortened to AMPLS, lets you connect private endpoints in your virtual network to Azure Monitor resources, including workspaces. Traffic stays on the Microsoft backbone and public access can be disabled for ingestion, for queries, or for both. A single scope can hold several workspaces and monitoring resources, and the endpoint resolves private addresses for the Azure Monitor domain names.

Design points

flowchart LR
  VNET["Virtual network with private endpoint"] --> AMPLS["Azure Monitor Private Link Scope"]
  ONP["On premises via VPN or ExpressRoute"] --> VNET
  AMPLS --> WS1["Workspace A"]
  AMPLS --> WS2["Workspace B"]
  INET["Public internet"] -. blocked when public access disabled .-> WS1
        

Collected data pays back when it triggers action or informs people.

Log alerts

A log search alert runs a query on a schedule and fires when results meet a condition, for example when the count of failed sign-ins crosses a limit. Alerts then trigger action groups that notify people, open tickets, or run automation. Each alert query runs against the workspace and is itself a cost and a load, so design them with narrow time windows and efficient filters. Alerts depend on Analytics tables, with only simple alerts on Basic tables.

Workbooks and dashboards

Good alert hygiene

Connecting alerts to action

An alert is only as useful as the response behind it. Action groups can email, send mobile notifications, call webhooks, create tickets, or start automation that restarts a service or isolates a machine. For serious conditions, route to an on-call rotation. For informational ones, send a daily digest instead of a flood of messages. Include a link to the exact query and a short note about the first thing to check, so the person who wakes at night does not have to rediscover the system. Test the whole chain regularly with a deliberate, harmless trigger.

The workspace is the common foundation under several Microsoft products.

The Sentinel effect on design

Enabling Sentinel on a workspace changes the billing for all its data, including operational logs that have nothing to do with security. This is why many organizations keep a dedicated Sentinel workspace for security data, and others combine to reach a larger commitment tier. The right answer comes from modeling the volumes and discounts for your own estate.

Sharing one foundation across tools

Because many products read the same tables, a change in one place can surprise another. Renaming a column in a custom table can break a security rule. Shortening retention can delete data an investigation needed. Adding a very noisy source can push a shared workspace into a different cost band for everyone. Maintain a simple list of which teams and products depend on each major table, and require a short notice before changes. A modest amount of coordination prevents most of the cross-team incidents that otherwise appear in shared platforms.

Costs follow volume, so understanding the meters is essential. Always confirm exact prices on Microsoft’s current pricing page, since they vary by region and change over time.

What you are billed for

Pay-as-you-go versus commitment tiers

A commitment tier lasts thirty-one days from selection. You can move up during the period, which restarts the clock, but you cannot move down until it ends, except for a short correction window of about six hours after changing. Commitment tiers apply only to Analytics tables, so moving high-volume data to cheaper plans reduces how much volume counts toward the commitment. Enterprise Agreement and other Azure discounts apply to commitment pricing.

A worked cost illustration

Suppose a company ingests one hundred and twenty gigabytes a day into Analytics tables, of which forty gigabytes come from a single verbose firewall table. If the firewall data moves to a cheaper plan after summary tables take over its dashboards, Analytics volume falls to eighty gigabytes. The company then no longer reaches the hundred gigabyte tier on that table set alone, so it must decide whether combining with another workspace restores the discount, or whether pay-as-you-go on the smaller volume is now cheaper than committing. The lesson is that every optimization changes the pricing decision, so recalculate after each major change instead of treating the tier as permanent.

Savings come from a handful of repeatable steps, in a sensible order.

Typical heavy hitters

Building a cost review ritual

A one-time cleanup decays within months, because new applications and settings add data again. Create a monthly review of fifteen minutes with the platform owner and a finance partner. Look at the five largest tables, the biggest changes since last month, any table with rising volume and falling queries, and any workspace approaching a tier boundary. Record each decision and the owner who must act. Over a year, this small habit prevents more waste than any single dramatic project, and it builds a shared understanding that logs are a product with a price, not a free by-product of running systems.

Surprises come from sudden floods of data. Guardrails limit the damage.

Daily cap

A daily cap sets a maximum amount of billable data per day. When the cap is reached, ingestion of most billable data stops until the next day. This protects the budget but also creates blind spots at exactly the moment something unusual is happening, which is when you most need logs. Some data types are exempt from the cap. Use caps as a safety net on non-critical, development, or test workspaces, and consider alerts instead of hard stops for production.

Spotting anomalies early

Forecasting and budgeting

Cost forecasting for logs is easier than it looks. Take the daily billed volume per table over the last ninety days, note growth trends, and add expected changes such as new applications or planned migrations. Multiply by the unit price of the relevant plan and add retention and query charges for cheaper plans. Present the result to owners as a range, with the main assumptions written beside it. When the real number drifts outside the range, investigate quickly, because early drift is nearly always a single misconfigured source rather than a gradual change.

Fast queries save time and money, and reliable ingestion saves investigations.

Why queries are slow

Reliability of the pipeline

Data can fail to arrive for many reasons: an agent stopped, a network path blocked, a rule removed, a daily cap reached, a schema mismatch, or a throttled sender. Build checks that confirm each important source is still reporting. Heartbeat records from machines, expected-volume alerts per table, and ingestion latency queries give you early warning of silent gaps.

Resilience across regions

A workspace belongs to one region. For critical data, you can send logs to workspaces in more than one region, and for some scenarios use workspace replication where supported. Alerts and workbooks do not move automatically if a region fails, so keep their definitions as templates ready to deploy against the alternate workspace.

Designing for both people and machines

Interactive investigators tolerate a few seconds of waiting, but alert rules and dashboards run constantly and magnify any inefficiency. A query that scans a day of data every five minutes will scan the same records hundreds of times. Move repeating logic into summary tables, keep alert windows short, and avoid expensive joins in scheduled queries. Review the slowest and most frequent queries regularly, since they combine to create most of the load. Faster, cheaper queries also leave room for analysts to explore without worrying about cost or timeouts, which improves the quality of investigations.

A workspace grows messy unless someone owns it. A light operating model prevents drift.

Roles

Enforcement with Azure Policy

Azure Policy can require a diagnostic setting on supported resources, deploy agents and rule associations to machines, restrict workspace creation to approved regions, and audit workspaces that lack required settings such as private access or retention. Policies turn written standards into automatic behavior, and they fix gaps that appear when new resources are created.

Naming and tagging

Meaningful workspace names show purpose and region at a glance. Tags on workspaces and rules record owner, environment, and cost center, which makes chargeback and cleanup possible.

flowchart TD
  STD["Logging standard: what to collect, plan, retention"] --> POL["Azure Policy enforces settings"]
  POL --> RES["New and existing resources"]
  RES --> WS["Shared workspaces"]
  WS --> REP["Monthly usage and cost report per owner"]
  REP --> REV["Quarterly review of tables, plans, retention"]
  REV --> STD
        

Documenting the standard

A logging standard works best as a short, living document. It lists which sources must send logs, which categories are required, which tables are mandatory for security, what plan and retention each class of data receives, and who approves exceptions. Add examples of good and bad requests, so teams can see how decisions are made. When a new service appears, the standard tells the owner exactly what to do on day one, and policy checks whether they did it. This turns monitoring from a favor requested from a central team into a normal part of delivering any workload.

Moving off the HTTP Data Collector API and the older agent is the most time-sensitive task for many estates.

Step by step

Testing a migration safely

Before converting anything important, copy a small sample of data through the new path and compare it with the old. Check record counts, column values, timestamps, and the behavior of every alert, workbook, and saved function that reads the table. Keep a rollback plan for the side-by-side approach, which is simply to leave the old table running until the new one is trusted. Communicate dates to application owners well in advance, because the people who wrote the original senders may have left, and their scripts may be running on forgotten machines.

Experience from many estates shows a few recurring good and bad designs.

Three short stories show how the concepts combine.

A quick reference of what experienced teams do and what they avoid.

Most problems fall into a few families. Work through them in order.

flowchart TD
  S["Expected logs are missing"] --> Q1{"Is it one source or many?"}
  Q1 -- Many --> Q2{"Daily cap reached or workspace unreachable?"}
  Q2 -- Yes --> F1["Check cap, network settings, private link modes"]
  Q2 -- No --> F2["Check rule changes and policy deployments"]
  Q1 -- One --> Q3{"Machine or Azure resource?"}
  Q3 -- Machine --> F3["Check agent health, rule association, endpoints"]
  Q3 -- Azure resource --> F4["Check diagnostic setting and categories"]
  Q3 -- Custom sender --> F5["Check identity, rule stream, schema, size, TLS"]
        

Escalating with good evidence

When a problem needs support from another team or from Microsoft, gather evidence first. Note the workspace identifier, the table, the time range, the exact symptom, and what you already tried. Include sample records that arrived and records that did not, plus any recent changes to rules, policies, or network settings. Clear evidence shortens resolution dramatically, and writing it down often reveals the answer before anyone else reads it. Afterwards, add the lesson to the troubleshooting playbook so the next person solves the same problem faster.

Short answers to questions that beginners and architects ask most often.

A Log Analytics workspace is Azure’s central, queryable home for log data. Good outcomes come from deliberate choices about what enters, where it sits, how long it stays, and who may read it.