No Data in Workspace¶

1. Summary¶

You open a Log Analytics workspace and the results are empty, stale, or missing for tables that normally update every few minutes. This playbook applies when the symptom appears broader than a single KQL mistake: multiple tables are stale, a newly connected resource never starts sending data, or data stopped after a change to cost controls, DCRs, network routing, or diagnostic settings.

In Azure Monitor, "no data" is usually a routing or governance problem before it is a workspace platform problem. Microsoft Learn guidance points first to daily cap, DCR association, diagnostic settings, agent health, and endpoint reachability. Use this playbook to separate true workspace ingestion stops from source-specific breaks and from delayed ingestion that only looks like data loss.

Typical incident window: 15-30 minutes from first symptom to operator detection for workspace freshness incidents. Time to resolution: 30 minutes to 2 hours depending on whether the break is cap, DCR, diagnostic settings, or endpoint reachability.

Use it when:

• Heartbeat, Perf, AzureDiagnostics, or AzureActivity look older than expected.
• Multiple resources stopped reporting around the same change window.
• One team claims the workspace is broken, but another team sees partial data.
• You need a falsifiable path to prove whether the break is at the workspace, DCR, resource, or network layer.

flowchart TD
    A[No fresh results in workspace] --> B{Any cap or ingestion warnings?}
    B -->|Yes| C[Daily cap or throttling path]
    B -->|No| D{Any source still sending?}
    D -->|No| E[Agent or diagnostic settings path]
    D -->|Yes| F{Late ingestion only?}
    F -->|Yes| G[Measure ingestion delay]
    F -->|No| H[DCR, identity, or endpoint path]
    C --> I[Raise cap or reduce volume]
    E --> J[Repair source configuration]
    H --> K[Repair routing and access]

2. Common Misreadings¶

3. Competing Hypotheses¶

4. What to Check First¶

1. Confirm workspace control-plane state and retention

   az monitor log-analytics workspace show \
       --resource-group $RG \
       --workspace-name $WORKSPACE_NAME \
       --query "{name:name,provisioningState:provisioningState,retentionInDays:retentionInDays,sku:sku.name}"
   

2. Check whether the workspace cap is stopping ingestion

   az monitor log-analytics workspace show \
       --resource-group $RG \
       --workspace-name $WORKSPACE_NAME \
       --query "workspaceCapping"
   

3. Run a control heartbeat query against the workspace

   az monitor log-analytics query \
       --workspace $WORKSPACE_ID \
       --analytics-query "Heartbeat | where TimeGenerated > ago(15m) | summarize LastHeartbeat=max(TimeGenerated) by Computer | order by LastHeartbeat asc" \
       --timespan "PT15M"
   

4. Verify that the resource still has diagnostic settings targeting the expected workspace

   az monitor diagnostic-settings list \
       --resource $RESOURCE_ID \
       --output json
   

5. Verify that AMA-backed resources still have a DCR association

   az monitor data-collection rule association list \
       --resource $RESOURCE_ID \
       --output json
   

6. Check whether the Azure Monitor Agent extension is still installed on the VM

   az vm extension list \
       --resource-group $RG \
       --vm-name $VM_NAME \
       --query "[].{name:name,provisioningState:provisioningState,publisher:publisher}"
   

5. Evidence to Collect¶

5.1 KQL Queries¶

// Operation log evidence for ingestion controls
Operation
| where TimeGenerated > ago(3d)
| where OperationCategory in ("Data Collection Status", "Ingestion", "Workspace")
| project TimeGenerated, OperationCategory, OperationName, OperationDetail, OperationStatus
| order by TimeGenerated desc

// Workspace freshness by major table
union isfuzzy=true
    (Heartbeat | summarize LastSeen=max(TimeGenerated), Rows=count() by TableName="Heartbeat"),
    (AzureActivity | summarize LastSeen=max(TimeGenerated), Rows=count() by TableName="AzureActivity"),
    (Perf | summarize LastSeen=max(TimeGenerated), Rows=count() by TableName="Perf"),
    (AzureDiagnostics | summarize LastSeen=max(TimeGenerated), Rows=count() by TableName="AzureDiagnostics")
| extend MinutesSinceLastSeen = datetime_diff('minute', now(), LastSeen) * -1
| order by MinutesSinceLastSeen desc

// Measure whether data is late rather than absent
union isfuzzy=true Heartbeat, Perf, AzureActivity
| where TimeGenerated > ago(6h)
| extend DelayMinutes = datetime_diff('minute', ingestion_time(), TimeGenerated)
| summarize AvgDelay=avg(DelayMinutes), P95Delay=percentile(DelayMinutes, 95), MaxDelay=max(DelayMinutes) by Type
| order by P95Delay desc

// Identify stale AMA or VM reporting scope
Heartbeat
| where TimeGenerated > ago(3d)
| summarize LastHeartbeat=max(TimeGenerated) by Computer, OSType, _ResourceId
| order by LastHeartbeat asc
| take 20

5.2 CLI Investigation¶

# Review workspace state and capping settings
az monitor log-analytics workspace show \
    --resource-group $RG \
    --workspace-name $WORKSPACE_NAME \
    --output json

Sample output:

{
  "customerId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "id": "/subscriptions/<subscription-id>/resourceGroups/rg-monitor/providers/Microsoft.OperationalInsights/workspaces/law-prod",
  "location": "eastus",
  "name": "law-prod",
  "provisioningState": "Succeeded",
  "retentionInDays": 30,
  "workspaceCapping": {
    "dailyQuotaGb": 5,
    "quotaNextResetTime": "2026-04-06T00:00:00Z"
  }
}

Interpretation:

• provisioningState should remain Succeeded.
• A low dailyQuotaGb is enough to explain a predictable same-day stop.
• quotaNextResetTime explains why data may reappear without any other fix.

# Check DCR associations on an affected source resource
az monitor data-collection rule association list \
    --resource $RESOURCE_ID \
    --output json

Sample output:

[
  {
    "dataCollectionRuleId": "/subscriptions/<subscription-id>/resourceGroups/rg-monitor/providers/Microsoft.Insights/dataCollectionRules/dcr-prod-vm",
    "description": "Baseline VM logs and metrics",
    "name": "ama-baseline",
    "provisioningState": "Succeeded"
  }
]

Interpretation:

• An empty array means AMA has nowhere to send streams from that resource.
• A wrong dataCollectionRuleId explains why one machine differs from the rest of the fleet.
• If the association exists, continue to local service logs and endpoint reachability.

# Verify diagnostic settings still target the expected workspace
az monitor diagnostic-settings list \
    --resource $RESOURCE_ID \
    --output json

Sample output:

[
  {
    "id": "/subscriptions/<subscription-id>/resourceGroups/rg-app/providers/Microsoft.Web/sites/app-prod/providers/microsoft.insights/diagnosticSettings/send-to-law",
    "logs": [
      {
        "categoryGroup": "allLogs",
        "enabled": true
      }
    ],
    "metrics": [
      {
        "category": "AllMetrics",
        "enabled": true
      }
    ],
    "workspaceId": "/subscriptions/<subscription-id>/resourceGroups/rg-monitor/providers/Microsoft.OperationalInsights/workspaces/law-prod"
  }
]

Interpretation:

• No result means the resource never writes platform logs to this workspace.
• A workspaceId mismatch explains why the application team says logging works while this workspace stays empty.
• Disabled category groups create table-specific gaps that look like ingestion failure.

# Check Azure Monitor Agent extension presence on a VM
az vm extension list \
    --resource-group $RG \
    --vm-name $VM_NAME \
    --output table

Sample output:

Name                    Publisher                   ProvisioningState
----------------------  --------------------------  -----------------
AzureMonitorLinuxAgent  Microsoft.Azure.Monitor     Succeeded

Interpretation:

• Missing AMA extension is enough to explain stale Heartbeat.
• Succeeded only proves deployment, not current runtime health.
• If the extension is present, move next to guest logs, identity, and network tests.

6. Validation and Disproof by Hypothesis¶

Hypothesis 1: Workspace daily cap was reached¶

Proves if: Operation shows cap warnings, the configured quota is low, and ingestion resumes after reset or after raising the cap. Disproves if: No cap signals exist and the quota is effectively unlimited or comfortably above observed usage. Test with: Section 5.1 Query 1 plus Section 5.2 CLI command 1.

Hypothesis 2: Diagnostic settings or DCR associations are missing or changed¶

Proves if: Affected resources lack diagnostic settings or DCR association while unaffected resources keep their expected configuration. Disproves if: Configuration is present, consistent, and still points to the right workspace. Test with: Section 5.1 Query 4 plus Section 5.2 CLI commands 2 and 3.

Hypothesis 3: Agents or monitored resources stopped sending¶

Proves if: Heartbeat is stale, extension state is missing or unhealthy, or guest-side AMA logs show token, service, or configuration failures. Disproves if: Heartbeats remain fresh while only one downstream table is affected. Test with: Section 5.1 Query 4 and Section 5.2 CLI command 4; then inspect Windows AMA logs under C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent or Linux AMA logs under /var/opt/microsoft/azuremonitoragent/log.

Hypothesis 4: Network path to Azure Monitor endpoints is blocked¶

Proves if: DCR and agent state look correct but the source cannot reach Azure Monitor ingestion endpoints, DCE, or IMDS. Disproves if: Endpoint access is healthy and another cause explains the stop more directly. Test with: Section 5.2 CLI command 2 to confirm the expected DCR path, then validate Azure Monitor and IMDS endpoint reachability from the affected host.

Hypothesis 5: Ingestion delay or throttling is being mistaken for total loss¶

Proves if: ingestion_time() shows large delays and data eventually arrives without configuration repair. Disproves if: No new rows appear during an extended observation window. Test with: Section 5.1 Queries 2 and 3.

Hypothesis 6: Workspace or subscription state is abnormal¶

Proves if: Workspace or subscription state is disabled, deleted, or not provisioned normally. Disproves if: Control-plane state is healthy. Test with: Section 4 checks 1 and 6, plus az account show --query "{subscriptionId:id,name:name,state:state}".

7. Likely Root Cause Patterns¶

Normal vs Abnormal Comparison¶

8. Immediate Mitigations¶

1. Raise the daily cap temporarily if production telemetry is blocked by quota.

   az monitor log-analytics workspace update \
       --resource-group $RG \
       --workspace-name $WORKSPACE_NAME \
       --quota 10
   

2. Recreate the DCR association for an affected AMA source.

   az monitor data-collection rule association create \
       --name ama-baseline \
       --resource $RESOURCE_ID \
       --rule-id $DCR_ID
   

3. Restore diagnostic settings on a resource whose platform logs stopped flowing.

   az monitor diagnostic-settings create \
       --name send-to-law \
       --resource $RESOURCE_ID \
       --workspace $WORKSPACE_ID \
       --logs '[{"categoryGroup":"allLogs","enabled":true}]' \
       --metrics '[{"category":"AllMetrics","enabled":true}]'
   

4. Restart AMA after configuration repair and confirm new heartbeat.

   az vm run-command invoke \
       --resource-group $RG \
       --name $VM_NAME \
       --command-id RunShellScript \
       --scripts "sudo systemctl restart azuremonitoragent"
   

5. Widen lookback windows if delayed ingestion is the only immediate issue.

   az monitor scheduled-query update \
       --resource-group $RG \
       --name $ALERT_RULE_NAME \
       --evaluation-frequency 10m \
       --window-size 15m
   

9. Prevention¶

Prevent workspace-wide data gaps by treating routing, cost, and freshness as separate controls. Microsoft Learn guidance is consistent here: avoid relying on daily cap as a normal operating control, keep DCR and diagnostic settings under repeatable configuration management, and monitor collection freshness directly.

Use DCR review as part of every onboarding and rebuild flow.

az monitor data-collection rule show \
    --resource-group $RG \
    --name $DCR_NAME \
    --query "{name:name,dataFlows:dataFlows,destinations:destinations}"

Prefer filtering and table plan decisions over hard workspace stoppage.

az monitor log-analytics workspace table update \
    --resource-group $RG \
    --workspace-name $WORKSPACE_NAME \
    --name AppServiceHTTPLogs \
    --plan Basic

Keep diagnostic settings explicit and auditable.

az monitor diagnostic-settings list \
    --resource $RESOURCE_ID \
    --output table

Create an explicit freshness alert so stale ingestion becomes visible quickly.

az monitor scheduled-query create \
    --name "workspace-freshness-alert" \
    --resource-group "$RG" \
    --scopes "$WORKSPACE_ID" \
    --condition "count 'StaleHeartbeat' > 0" \
    --condition-query "StaleHeartbeat=Heartbeat | where TimeGenerated < ago(15m)" \
    --evaluation-frequency "5m" \
    --window-size "5m" \
    --severity 2 \
    --skip-query-validation true \
    --description "Trigger when heartbeat data in the workspace is older than fifteen minutes." \
    --output json

Finally, keep at least one control-plane stream such as AzureActivity landing in the workspace. It gives you a fast discriminator between a true workspace problem and a source-specific collection failure.

See Also¶

• Agent Not Reporting
• High Ingestion Cost
• Operations: Cost Control
• Operations: Data Collection Rules
• KQL: Ingestion Volume

Sources¶

• Microsoft Learn: Troubleshoot data collection in Azure Monitor Logs
• Microsoft Learn: Manage cost and usage in Log Analytics workspaces
• Microsoft Learn: Azure Monitor Agent overview
• Microsoft Learn: Data collection rules in Azure Monitor
• Microsoft Learn: Create diagnostic settings in Azure Monitor
• Microsoft Learn: Heartbeat table reference
• Microsoft Learn: AzureDiagnostics table reference
• Microsoft Learn: Log data ingestion time in Azure Monitor