How to Fix Azure Monitor

This is where I start every Azure Monitor troubleshooting session. The agent is the foundation, if it's broken, everything downstream is meaningless.

On Windows, the Azure Monitor Agent writes its operational logs to two locations. First, check the Windows Event Log. Open Event Viewer, navigate to Applications and Services Logs → Microsoft → Azure Monitor Agent → Agent. Look for error events. Event ID 3000 typically means a DCR download failure. Event ID 5003 means a data upload failure, often network-related.

Second, check the agent's own log files at:

C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent\

Open the most recent .log file and look for lines containing ERROR or FATAL. A common one is:

Failed to download DCR configuration. StatusCode: 403. Ensure managed identity has correct RBAC assignment.

That 403 tells you the VM's managed identity doesn't have the Monitoring Metrics Publisher or Log Analytics Contributor role on the workspace. Fix it in IAM on the workspace resource.

On Linux, check:

sudo cat /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/extension.log

And the agent-level logs at:

sudo journalctl -u azuremonitoragent -n 100 --no-pager

If the agent is healthy in logs but still not sending data, move to the network layer. From the VM, test connectivity to the ingestion endpoint:

Test-NetConnection -ComputerName "global.handler.control.monitor.azure.com" -Port 443

If TcpTestSucceeded comes back False, you've found your issue, a firewall or NSG is blocking the agent. You'll need to allow outbound HTTPS to the Azure Monitor service tags: AzureMonitor and AzureActiveDirectory.

Data Collection Rules are the most common source of Azure Monitor troubleshooting headaches in environments that migrated from MMA to AMA after 2023. People install the new agent but forget that DCRs are now required for every data source, the agent collects nothing without them.

Navigate to Azure Monitor → Data Collection Rules in the Portal. You'll see a list of all DCRs in your subscription. Click on the one targeting your affected VMs and check three things:

Data sources: Click Data sources in the left menu. Confirm the data sources you expect are listed, Windows Event Logs, Performance Counters, Syslog, etc. If this list is empty, the DCR exists but collects nothing. Add the data sources you need.

Destinations: Click Destinations. Confirm your Log Analytics workspace is listed as a destination. If the workspace was deleted and recreated, the resource ID here will be stale and the association silently broken.

Resources: Click Resources. Every VM or Arc-enabled server that should use this DCR must appear here. If your VM is missing, click Add and associate it.

You can also verify and fix DCR associations via PowerShell, which is much faster when dealing with tens of machines:

# List all DCR associations for a VM
$vmResourceId = "/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vmName}"
Get-AzDataCollectionRuleAssociation -TargetResourceId $vmResourceId

# Create a new association
New-AzDataCollectionRuleAssociation `
  -TargetResourceId $vmResourceId `
  -AssociationName "myDCRAssociation" `
  -RuleId "/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Insights/dataCollectionRules/{dcrName}"

After fixing the DCR, wait up to 5 minutes and re-run the Heartbeat query from Step 1. You should start seeing data flow.

I know this is frustrating, especially when you're certain you have access, but workspace permissions are one of the sneakiest causes of data gaps in Azure Monitor troubleshooting. Access to a VM and access to its Log Analytics workspace are completely separate RBAC hierarchies.

Go to your Log Analytics workspace in the Portal. Click Access control (IAM) in the left menu. Check that the following identities have appropriate roles:

• VM Managed Identity, needs Monitoring Metrics Publisher on the workspace, or Log Analytics Contributor at minimum.
• Users querying Logs, need Log Analytics Reader to view data, or Log Analytics Contributor to modify saved queries and alerts.
• Action Groups using a Runbook or Function, the service principal behind the action needs Contributor access to the target resource.

Also check the workspace's Access control mode. Go to Properties in the workspace left menu. Under Access control mode, you'll see either Use workspace permissions or Use resource or workspace permissions. If it's set to the latter, users may have access to logs for specific resources (via resource-level RBAC) but not the workspace itself, this causes confusing scenarios where some tables are visible and others aren't.

For workspaces used across multiple teams, I'd recommend switching to Use workspace permissions and managing access at the workspace level. It's less granular but dramatically easier to troubleshoot.

Finally, verify the workspace isn't hitting its daily cap. Go to Usage and estimated costs in the workspace left menu. If you see a warning that the daily cap was reached, data ingestion silently stopped for the remainder of that 24-hour window. Either raise the cap or wait for the reset, it resets at midnight UTC.

# Check ingestion volume via KQL
Usage
| where TimeGenerated > ago(7d)
| summarize TotalGB = sum(Quantity) / 1024 by bin(TimeGenerated, 1d), DataType
| order by TimeGenerated desc

Your logs are flowing, your metrics look fine, but the alert never fired when it should have. This is one of the most common Azure Monitor troubleshooting scenarios and it has several distinct causes.

First, check the alert rule's own history. Go to Azure Monitor → Alerts → Alert rules. Click on the specific rule. In the left menu, click History. This shows you every evaluation, including evaluations that ran but didn't trigger. Look for the pattern: is it evaluating at all, or are there gaps?

If evaluations are happening but not triggering, your threshold or time window may be wrong. A common mistake: setting a metric alert to trigger when CPU exceeds 90% using a 1-minute aggregation. A short spike hits 95% but a 1-minute average never crosses 90%. Change to a 5-minute aggregation and it will catch it.

If evaluations have gaps or errors, open the rule and look at the Condition. For log search alerts, click See last run results. You'll often see:

Query evaluation failed: The query could not be executed within the time limit.

This means your KQL query is too expensive. Optimize it, add where clauses early, avoid join on large tables without filters, and ensure you're using indexed columns like TimeGenerated and Computer.

Second issue: the rule fires but the action group fails. Check the action group separately. Go to Azure Monitor → Action groups, select your group, and click Test. This sends a test notification through every configured action (email, SMS, webhook, Logic App). If an email test doesn't arrive, check the email address, spam filters, and whether the action group is in the correct Azure region for the alert rule, cross-region action group calls have higher latency and occasional failures during regional incidents.

# Check recent alert firings via Azure CLI
az monitor activity-log alert list --output table

# Check action group test status
az monitor action-group test \
  --resource-group "myRG" \
  --name "myActionGroup" \
  --alert-type "metric"

Platform metrics for Azure resources, things like App Service CPU, SQL DTU consumption, or Storage Account transactions, don't require an agent. They're emitted automatically by the platform. But they only flow to your Log Analytics workspace if you configure Diagnostic Settings for each resource. If metrics are missing, this is almost always the cause.

Go to the affected resource (say, an App Service Plan). In the left menu under Monitoring, click Diagnostic settings. If the page is empty, no settings are configured. Click Add diagnostic setting.

Name it something meaningful. Then select which log categories and metrics to send. Check AllMetrics at minimum. Under Destination details, check Send to Log Analytics workspace and pick your workspace. Click Save.

Metrics typically appear in the workspace within 3–5 minutes. They land in the AzureMetrics table:

AzureMetrics
| where ResourceProvider == "MICROSOFT.WEB"
| where MetricName == "CpuPercentage"
| where TimeGenerated > ago(1h)
| summarize avg(Average) by bin(TimeGenerated, 5m), Resource
| render timechart

For large environments where you have dozens or hundreds of resources without Diagnostic Settings, doing this manually is impractical. Use Azure Policy to enforce it automatically. The built-in policy "Deploy Diagnostic Settings for App Service to Log Analytics workspace" (Policy ID: b4e2cfce-4be8-4dd7-a2d8-3cc3dbf7eaad) can be assigned at subscription level with a DeployIfNotExists effect, it will automatically create Diagnostic Settings on any App Service that doesn't have them.

# Assign the diagnostic settings policy via PowerShell
$assignment = New-AzPolicyAssignment `
  -Name "enforce-diag-appservice" `
  -PolicyDefinitionId "/providers/Microsoft.Authorization/policyDefinitions/b4e2cfce-4be8-4dd7-a2d8-3cc3dbf7eaad" `
  -Scope "/subscriptions/{subscriptionId}" `
  -PolicyParameterObject @{
    logAnalytics = "/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}"
  }

Once assigned, existing non-compliant resources need a remediation task. Go to Policy → Remediation and create a task for the assignment. Azure will automatically deploy Diagnostic Settings to every affected resource in scope.