Log Types in Azure: Which Log to Check for Which Problem

The four main log types

Before going into detail on each type, here is a summary of what they are for:

• Activity Logs: Who did what to Azure resources (control plane operations). Subscription-level.
• Resource Logs (Diagnostic Logs): What happened inside an Azure resource (data plane operations). Per-resource.
• Microsoft Entra ID Logs: Who signed in, what was changed in the directory. Tenant-level.
• Platform Metrics: Numeric performance data for Azure resources (CPU, request count, latency). Per-resource.

All four types flow through Azure Monitor, which is the umbrella platform that collects, routes, and queries log and metric data. Azure Monitor provides the diagnostic settings UI, the Log Analytics query interface, and the alert rule framework for all four log types.

Comparison table

Activity Logs in detail

Activity logs capture the what, who, and when of control plane actions. Every subscription has them enabled automatically. They are the default starting point for investigating “something changed in my subscription.”

The Log Analytics table name is AzureActivity. A basic KQL query to see recent administrative events:

AzureActivity
| where TimeGenerated > ago(24h)
| where CategoryValue == "Administrative"
| project TimeGenerated, Caller, OperationNameValue, ActivityStatusValue, ResourceGroup
| order by TimeGenerated desc

Key limitation: activity logs only show control plane. If you need to know who read a blob from a storage account, activity logs will not tell you — that is a resource log. For full details on querying activity logs, see Azure Activity Logs.

Resource Logs (Diagnostic Logs) in detail

Resource logs are the most varied and most important category for application security. Every Azure resource type produces different resource logs, and they are not collected by default — you must configure a diagnostic setting for each resource.

Examples of what resource logs capture per service:

• Azure Key Vault: Every secret read, write, delete, and list operation — including who called it (the managed identity or user principal), when, and what status was returned. Table: AzureDiagnostics or AzureKeyVaultAuditEvent.
• Azure Storage: Every blob read, write, delete operation with the authenticated identity, storage operation type, and response code. Table: StorageBlobLogs.
• Azure App Service: HTTP access logs (request method, URL, status code, response time). Table: AppServiceHTTPLogs.
• Azure SQL Database: Query execution, login attempts, failed authentication. Table: AzureDiagnostics with category SQLSecurityAuditEvents.
• Azure Firewall: Allowed and denied network flow logs. Table: AzureDiagnostics or the newer AzureFirewallNetworkRule / AzureFirewallApplicationRule.

Enabling resource logs via CLI

# Enable resource logs for a Key Vault, sending to Log Analytics
VAULT_ID=$(az keyvault show --name my-vault --resource-group my-rg --query id --output tsv)
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --workspace-name my-workspace \
  --resource-group my-rg \
  --query id \
  --output tsv)

az monitor diagnostic-settings create \
  --name "keyvault-diagnostics" \
  --resource "$VAULT_ID" \
  --workspace "$WORKSPACE_ID" \
  --logs '[
    {"category": "AuditEvent", "enabled": true}
  ]' \
  --metrics '[
    {"category": "AllMetrics", "enabled": true}
  ]'

Microsoft Entra ID Logs in detail

Entra ID logs are separate from Azure resource logs and activity logs. They live at the tenant level and cover identity operations — not resource management, but who is authenticating and what is changing in the directory.

There are two main categories:

• Sign-in logs: Every authentication event — interactive user logins, non-interactive logins (background token refreshes), service principal sign-ins. Includes IP address, location, device, MFA result, conditional access policy result, and risk level.
• Audit logs: Every change to directory objects — user creation/deletion, group membership changes, app registration updates, role assignments within Entra ID (not Azure RBAC), password resets, MFA registration.

By default these are visible in the Entra ID portal for 7 days (free) or 30 days (P1/P2). Export to Log Analytics for longer retention and KQL queries:

# Export Entra ID logs to Log Analytics
# Note: this is done through the Entra ID Diagnostic Settings,
# not the standard az monitor diagnostic-settings command.
# The resource ID for Entra ID diagnostic settings is:
ENTRA_RESOURCE_ID="/tenants/$(az account show --query tenantId --output tsv)/providers/microsoft.aadiam"

az monitor diagnostic-settings create \
  --name "entra-id-logs" \
  --resource "$ENTRA_RESOURCE_ID" \
  --workspace "$WORKSPACE_ID" \
  --logs '[
    {"category": "SignInLogs", "enabled": true},
    {"category": "AuditLogs", "enabled": true},
    {"category": "NonInteractiveUserSignInLogs", "enabled": true},
    {"category": "ServicePrincipalSignInLogs", "enabled": true}
  ]'

Once in Log Analytics, sign-in logs appear in the SigninLogs table and audit logs in the AuditLogs table. These are essential for detecting suspicious sign-in patterns, which is covered in detail on the detecting suspicious activity page.

Platform Metrics in detail

Metrics are numeric, time-series measurements collected automatically for every Azure resource. Unlike logs (text/JSON events), metrics are aggregated numbers sampled at regular intervals (typically every minute). They are stored in the Azure Monitor Metrics store for 93 days and do not require any diagnostic setting to collect.

Common metric examples:

• Virtual Machines: CPU percentage, available memory bytes, disk read/write operations per second, network in/out bytes.
• App Service: Request count, average response time, HTTP 4xx/5xx error count, CPU time.
• Azure SQL: DTU consumption, storage percentage, connection count, deadlock count.
• Key Vault: Service API hit count, latency, availability.

Metrics are primarily used for performance monitoring and alert thresholds. They are less useful for security investigations (activity logs and resource logs are better there) but essential for capacity planning and SLO tracking.

You can send metrics to Log Analytics to combine them with log data in KQL queries:

# Check available metrics for a resource
az monitor metrics list-definitions \
  --resource "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/my-rg/providers/Microsoft.Web/sites/my-app" \
  --query "[].{Name:name.value, DisplayName:name.localizedValue}" \
  --output table

Where logs can go: Log Analytics, Storage, and Event Hub

All four log types can be sent to one or more destinations simultaneously:

• Log Analytics workspace: The best choice for interactive investigation, KQL queries, and alert rules. Slightly higher cost than storage. Data is searchable immediately after ingestion.
• Azure Storage Account: The cheapest option for long-term archival. Data is stored as JSON blobs. Not queryable interactively — you must download and parse the files. Good for compliance retention requirements where the logs must be preserved but are rarely accessed.
• Azure Event Hub: For streaming logs to external systems — SIEM tools like Splunk, Microsoft Sentinel (though Sentinel has direct connectors), or custom log processing pipelines. Provides a real-time stream rather than a queryable store.

Quick reference: which log to check for each problem

• ”Who created/deleted/modified this Azure resource?” → Activity Log (AzureActivity table)
• “Who was granted a role on this subscription?” → Activity Log, filter on Microsoft.Authorization/roleAssignments/write
• ”Who read this Key Vault secret?” → Key Vault Resource Log (AzureKeyVaultAuditEvent or AzureDiagnostics)
• “Why is my App Service returning 500 errors?” → App Service Resource Logs (AppServiceHTTPLogs, AppServiceConsoleLogs)
• “Did this user log in from a new country?” → Entra ID Sign-in Logs (SigninLogs table)
• “Who was added to Global Administrator in Entra ID?” → Entra ID Audit Logs (AuditLogs table)
• “Why is my VM CPU at 100%?” → Platform Metrics (Azure Monitor Metrics, not logs)
• “Did anyone access my storage blobs without authorization?” → Storage Resource Logs (StorageBlobLogs)
• “Which network flows were blocked by my firewall?” → Azure Firewall Resource Logs (AzureDiagnostics or firewall-specific tables)