Log Analytics workspaces

Design

Start with one workspace (per Entra tenant); data volume doesn't slow queries. Split only for a real reason: data residency per region, egress cost, separate billing or commitment tiers, or resilience (ingest into workspaces in two regions). Workspace-based Application Insights, diagnostic settings and agents all write into it.

Table plans and retention

• Tables keep data 30 days by default (some built-in tables 90). Analytics retention extends to two years; total retention (including low-cost long-term retention, reached through search jobs) to 12 years.
• Shortening total retention waits 30 days before deleting, so a mistake can be reverted; lengthening applies to data not yet removed.

Access

• Access control mode (features.enableLogAccessUsingOnlyResourcePermissions): Use resource or workspace permissions (true; the default since March 2019) lets anyone with read on a resource query that resource's logs in resource context; Require workspace permissions (false) needs a workspace or table role.
• Roles: Log Analytics Reader (read data and monitoring settings), Log Analytics Contributor (also configure), Log Analytics Data Reader (minimum query rights; for granular, condition-based RBAC). Querying needs Microsoft.OperationalInsights/workspaces/query/read; resource-context needs Microsoft.Insights/logs/<table>/read.
• Resource context works only for records with _ResourceId, only on Analytics tables, and for Application Insights only when it's workspace-based.
• features.disableLocalAuth turns off the workspace's shared-key authentication.

Daily cap

A daily cap stops collecting billable data in Analytics and Basic tables until the workspace's reset hour (fixed per workspace, not configurable); some data beyond the cap still lands. It's a budget guard, not a cost-saving tool: alert on it, because monitoring and alerts go blind once it's reached.

Querying from TypeScript

import { DefaultAzureCredential } from "@azure/identity";
import { LogsQueryClient, LogsQueryResultStatus, Durations } from "@azure/monitor-query-logs";

const credential = new DefaultAzureCredential();

// Query: needs Log Analytics Reader (or table/resource-level read) on the workspace.
export async function failedRequests(workspaceId: string): Promise<void> {
  const logs = new LogsQueryClient(credential);
  const kql = "AppRequests | where Success == false | summarize failures = count() by bin(TimeGenerated, 5m) | order by TimeGenerated desc";
  const result = await logs.queryWorkspace(workspaceId, kql, { duration: Durations.oneHour }, { serverTimeoutInSeconds: 120 });
  if (result.status === LogsQueryResultStatus.Success) {
    for (const row of result.tables[0]?.rows ?? []) console.log(row);
  } else {
    // PartialFailure: some data came back (limits, timeouts); don't treat it as complete. Full failures throw.
    console.warn(result.partialError.code, result.partialError.message);
  }
}

workspaceId is the workspace's customer ID (a GUID), not its resource ID; use queryResource with a resource ID for resource-context queries.