Azure Monitor Not Working? Fix Setup & Config Issues
Why Azure Monitor Isn't Behaving the Way You Expect
I've seen this exact problem on dozens of Azure environments: you spin up Azure Monitor, wire up a few resources, and then sit there wondering why your dashboards are empty, your alerts are silent, or your Log Analytics workspace looks like a ghost town. It's maddening , especially when you've followed every step in the wizard and the portal cheerfully told you "deployment succeeded."
Here's the honest truth. Azure Monitor isn't a single toggle you flip. It's Microsoft's unified observability service that pulls together metrics, logs, traces, and events from across your entire cloud and hybrid environment. That breadth is exactly why misconfiguring one piece , a Data Collection Rule, an agent version mismatch, a workspace in the wrong region, can silently break the whole pipeline without throwing a visible error. The Azure portal won't always tell you what went wrong. You have to know where to look.
The most common reasons I see Azure Monitor data collection fail in the field:
- No Log Analytics workspace attached. Metrics can flow without one, but logs and traces need a workspace destination configured. Skipping this step is the single most common oversight I see from teams new to Azure monitoring.
- Missing or misconfigured Data Collection Rules (DCRs). Modern Azure Monitor Agent-based collection is entirely DCR-driven. If your DCR isn't associated with the right resource or isn't scoping the right data sources, you get nothing.
- Azure Monitor Agent not installed or running on VMs. The old Log Analytics agent (MMA/OMS) is deprecated. If your virtual machines are still running the legacy agent, you're heading for a support cliff and potentially already missing data.
- Diagnostic settings not enabled on Azure resources. By default, Azure platform logs and resource metrics aren't sent anywhere. You have to explicitly configure a diagnostic setting per resource, per subscription, or at the management group level.
- Region and subscription mismatches. A Log Analytics workspace in East US won't automatically receive data from resources configured to send to West Europe. These routing mismatches are silent killers.
- Insufficient RBAC permissions. The contributor or reader role isn't enough for certain monitoring operations. I've watched engineers spend three hours debugging a "no data" problem that turned out to be a missing Monitoring Contributor assignment.
- Application Insights instrumentation key versus connection string confusion. If you're still using the deprecated instrumentation key instead of the connection string for Application Insights, data ingestion may silently fail on newer SDK versions.
What makes all of this harder is that Azure Monitor's error messages are often either nonexistent or buried inside activity logs that most people never check. Microsoft's official Azure Monitor documentation confirms the service is designed to collect from a wide variety of sources, but the configuration to make each source actually deliver data requires deliberate, source-specific setup. Nothing is automatic by default.
I know this is frustrating, especially when your team is trying to meet an SLA or troubleshoot a production incident right now. Let's fix it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep on agent reinstalls and KQL queries, run through this fast diagnostic. In my experience, roughly 60% of "Azure Monitor not working" tickets resolve at one of these three checkpoints.
Step 1, Verify your Log Analytics workspace exists and is the correct destination. Open the Azure portal, search for "Log Analytics workspaces" in the top search bar, and confirm you have an active workspace. Then go to your resource (a VM, for example), click Monitoring > Diagnostic settings in the left sidebar, and check whether a diagnostic setting exists that routes data to that workspace. If the setting is missing, that's your problem, click Add diagnostic setting, check the log and metric categories you want, select Send to Log Analytics workspace, choose your workspace, and hit Save. Done.
Step 2, Run a quick KQL sanity check. Go to your Log Analytics workspace, click Logs in the left sidebar, and run this query:
Heartbeat
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat > ago(30m)If you see your machines in the results, the Azure Monitor Agent is alive and talking to the workspace. If the query returns nothing, the agent is either not installed, not running, or not configured to target this workspace.
Step 3, Check Data Collection Rules are associated. Search for "Data Collection Rules" in the portal. Open your DCR and click Resources in the left menu. Your target VMs or Arc-connected machines need to appear here. If the list is empty, click Add, select your resources, and save. Data should start flowing within 5–10 minutes.
If you've done all three and still have no data, keep reading, the step-by-step below covers the full repair sequence.
The Log Analytics workspace is the backbone of Azure Monitor's log and trace collection. Think of it as the central database where all your KQL-queryable data lands. Without one properly configured, you can have agents running perfectly on every VM and still see nothing in your dashboards.
To create a workspace, navigate to the Azure portal and search for Log Analytics workspaces. Click Create, select your subscription and resource group, give it a meaningful name (I recommend something like law-prod-eastus-01 so region and environment are obvious at a glance), choose your region, and select a pricing tier. The Pay-as-you-go tier works for most teams starting out. Click Review + Create.
If you already have a workspace, verify these two things. First, check the retention setting under Settings > Usage and estimated costs > Data Retention. The default is 30 days. If you need longer retention for compliance or historical analysis, increase this now, you can't retroactively recover data you didn't retain. Second, verify the workspace is in the same region as your primary resources wherever possible. Cross-region data ingestion works but adds latency and egress cost.
One thing people miss: after creating the workspace, you still need to explicitly link resources to it. The workspace existing doesn't automatically pull data from anywhere. That linking happens either through Diagnostic Settings (for Azure platform resources), Data Collection Rules (for VMs and Arc servers), or Application Insights connection strings (for application telemetry). Each pathway is configured separately.
When it's working correctly, you'll see data appearing in the Logs blade of the workspace within minutes of configuration. Run the simple query search * | take 10 to confirm any data is arriving at all before going further.
If you're monitoring virtual machines, the Azure Monitor Agent (AMA) is your data collector. Microsoft has officially retired the legacy Log Analytics agent (also called the MMA or OMS agent), if your machines are still running it, migration to AMA is not optional, it's overdue. The legacy agent stopped receiving feature updates and will eventually stop working entirely.
To install the Azure Monitor Agent via the portal, navigate to your VM, click Extensions + applications in the left sidebar, then click Add. Search for Azure Monitor Agent and select it. For Windows VMs, the extension is named AzureMonitorWindowsAgent; for Linux, it's AzureMonitorLinuxAgent. Click through the wizard and hit Review + Create.
You can also install at scale using Azure Policy. Search for the built-in policy "Configure Windows virtual machines to run Azure Monitor Agent" and assign it at the subscription or management group level. This is the right approach for environments with more than a handful of VMs.
To verify the agent is running after installation, connect to the VM and check the service status:
# On Windows (PowerShell)
Get-Service -Name "AzureMonitorAgent"
# On Linux (bash)
systemctl status azuremonitoragentYou want to see Running on Windows or active (running) on Linux. If the service exists but is stopped, start it with Start-Service AzureMonitorAgent or sudo systemctl start azuremonitoragent and then investigate why it stopped using the Windows Event Viewer (Event ID 1000–1001 under Applications and Services Logs > Microsoft > AzureMonitorAgent) or the Linux journal logs.
A running agent alone isn't enough, it also needs a managed identity on the VM and an associated Data Collection Rule. If the agent is running but no data appears in your workspace, step 3 is your next stop.
Data Collection Rules (DCRs) are how Azure Monitor Agent-based collection actually works. A DCR defines what data to collect (Windows Event logs, Linux syslog, performance counters, text logs, etc.) and where to send it. The agent does exactly what its associated DCR says, nothing more, nothing less. If your DCR is wrong or missing, you get zero data regardless of how healthy the agent is.
To create a DCR, search for Data Collection Rules in the portal, click Create, and work through the wizard. Key decisions:
- Platform type: Choose Windows, Linux, or Custom depending on your sources.
- Data sources: Add Windows Event Logs, Performance Counters, Linux Syslog, or Text Logs as needed. For Windows Event Logs, I always add at minimum the System, Application, and Security channels at the Warning level or above as a baseline.
- Destination: Select Azure Monitor Logs and point it to your Log Analytics workspace. You can also add Azure Monitor Metrics destination here for performance counter data.
After creating the DCR, the most overlooked step is associating it with resources. Click Resources in the DCR blade and add your VMs. Without this association, the DCR exists but the agent never receives its instructions.
You can verify a DCR association is working by running this KQL query in your Log Analytics workspace about 10 minutes after associating:
Perf
| where TimeGenerated > ago(15m)
| summarize count() by Computer, ObjectNameIf you configured performance counters in the DCR and you see your machines and counter names in the results, the DCR pipeline is working end to end.
Here's something that catches a lot of people off guard: Azure services like Storage Accounts, Azure SQL, Key Vault, App Service, and dozens of others do not send monitoring data to Azure Monitor by default. You have to opt each resource in by creating a Diagnostic Setting. This is separate from the VM-based agent setup, platform-level logs flow through a completely different pipeline.
For each Azure resource you want to monitor, navigate to the resource in the portal, scroll down the left sidebar to the Monitoring section, and click Diagnostic settings. Click Add diagnostic setting, give it a name, check the log and metric categories you want (I recommend selecting all categories initially, you can prune later), then under Destination details check Send to Log Analytics workspace and select your workspace. Save it.
For audit and security logs at the subscription level, go to Monitor > Activity log, click Export Activity Logs, and create a diagnostic setting that routes subscription-level activity to your workspace. This captures control-plane operations, who deployed what, who changed a role assignment, who deleted a resource group. This data is invaluable during incident response.
For Entra ID (Azure Active Directory) sign-in and audit logs, those are configured separately in the Entra ID portal under Monitoring > Diagnostic settings. Microsoft's documentation confirms that Entra ID audit logs are collected into the same Azure Monitor data platform, but they need their own diagnostic setting pointed at your workspace.
Once diagnostic settings are saved, allow 5–15 minutes for data to start flowing, then verify with:
AzureActivity
| where TimeGenerated > ago(1h)
| summarize count() by OperationNameValue, ActivityStatusValue
| order by count_ descYou set up an alert, something clearly went wrong in your environment, and the alert sat there in silence. I see this constantly. The good news: Azure Monitor alert failures almost always come down to one of four things, wrong signal type, bad query logic, an action group that's misconfigured, or the alert being in a disabled or "fired but suppressed" state.
Start by going to Monitor > Alerts and checking the Alert rules tab. Look at the State column. An alert rule can be Enabled, Disabled, or have a Suppression Rule applied. Suppression (now called Action Rules) can silently mute alerts during maintenance windows, check Monitor > Alerts > Action rules to see if any muting rules are active.
For metric-based alerts, verify the signal and threshold by clicking into the alert rule and reviewing the condition. Use the Preview chart to see whether the metric actually crossed your threshold in the relevant time window. If the chart shows the metric did cross the threshold but the alert didn't fire, check the evaluation frequency and aggregation period, a 5-minute evaluation window on a metric that spikes for 2 minutes won't catch it.
For log-based alerts built on KQL queries, test the query independently in Log Analytics first:
// Example: alert on high CPU using Perf table
Perf
| where ObjectName == "Processor"
and CounterName == "% Processor Time"
and InstanceName == "_Total"
| where CounterValue > 90
| summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), ComputerRun this query manually. If it returns results for your incident window, the query is correct. If it returns nothing, your data isn't there, go back to DCR and diagnostic settings troubleshooting.
For Action Groups (the notification config), navigate to Monitor > Action groups, open your group, and click Test action group. You can send a test notification to verify email, SMS, webhook, or Logic App actions are actually reachable. This takes 30 seconds and eliminates a huge class of "why didn't I get an alert" problems instantly.
Advanced Troubleshooting
If the standard steps didn't resolve your Azure Monitor issues, it's time to go deeper. These are the scenarios I see in larger enterprise environments, RBAC problems, workspace design mistakes, Application Insights connection failures, and hybrid monitoring gaps.
RBAC Permission Gaps
Azure Monitor has its own set of built-in roles that go beyond standard reader/contributor access. The Monitoring Reader role allows reading metrics and alert activity but not modifying alert rules or workbooks. The Monitoring Contributor role is needed to create and edit alert rules, DCRs, and action groups. If a team member says "I can see the workspace but can't configure alerts," a missing Monitoring Contributor assignment on the subscription or resource group is the likely cause.
Check role assignments by going to the relevant resource or subscription, clicking Access control (IAM), and then Check access. Enter the user or service principal name and see what roles are assigned.
Application Insights Connection String Errors
If your application telemetry isn't arriving in Application Insights, the first thing I check is whether the SDK is using the connection string or the deprecated instrumentation key. The connection string contains the instrumentation key plus the endpoint URLs for regional ingestion, it's more reliable and required for newer Application Insights features including OpenTelemetry-based collection.
Your connection string lives in your Application Insights resource under Overview > Connection String. It looks like:
InstrumentationKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;IngestionEndpoint=https://eastus-8.in.applicationinsights.azure.com/;LiveEndpoint=https://eastus.livediagnostics.monitor.azure.com/Set this as the environment variable APPLICATIONINSIGHTS_CONNECTION_STRING in your app service or container configuration. For .NET apps, you can also set it in appsettings.json. Restart the application after changing this value.
Azure Monitor Agent Connectivity Verification
The Azure Monitor Agent needs outbound HTTPS connectivity to several Microsoft endpoints. In locked-down network environments with strict NSG rules or proxy configurations, the agent may install cleanly but fail to send data. On Windows, check the agent log at:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent\Look for entries containing HttpRequestException or SSL, these point to network connectivity or certificate validation failures. On Linux, check:
sudo journalctl -u azuremonitoragent -n 200 --no-pagerPrometheus Metrics and Azure Monitor Workspaces
If you're running Kubernetes and using the Azure Monitor managed service for Prometheus, be aware that Prometheus metrics go to an Azure Monitor workspace, this is a different resource type from a Log Analytics workspace. They're analyzed with PromQL, not KQL, and visualized through Grafana. A common mistake is querying Prometheus metrics in Log Analytics and wondering why nothing shows up. They're in separate stores by design, and the right query tool is either Grafana connected to your Azure Monitor workspace or the Metrics Explorer using PromQL mode.
Hybrid and Arc-Connected Resources
For on-premises or multi-cloud servers connected via Azure Arc, the monitoring setup is nearly identical to Azure VMs, install Azure Monitor Agent, create DCRs, associate them with your Arc-connected machines. The key difference is that Arc machines need the Azure Connected Machine agent running in addition to the Azure Monitor Agent. Check Arc agent health by running:
# Windows PowerShell
azcmagent show
# Linux bash
sudo azcmagent showLook for Agent Status: Connected. If the Arc agent shows as disconnected, the Azure Monitor Agent won't be able to reach Azure endpoints for authentication even if the monitoring agent itself is running.
There are situations where self-service troubleshooting genuinely hits a wall and you need Microsoft involved. Escalate to Microsoft Support if you're seeing data ingestion gaps you can't explain, especially if Heartbeat data shows the agent is running but specific log tables (like Event or Syslog) are empty despite correct DCR configuration. Also escalate if you're seeing billing anomalies in your Log Analytics workspace that don't match expected ingestion volumes, or if Application Insights is returning HTTP 429 (throttling) errors that persist beyond 24 hours. For production incidents with SLA impact, open a Severity A support ticket, don't use the free community forum for those.
Prevention & Best Practices
The engineers I know who never have Azure Monitor emergencies aren't smarter than everyone else, they just built the right habits into their infrastructure-as-code workflows from the start. Here's what actually prevents the pain.
Deploy monitoring configuration as code, not through the portal. Every Diagnostic Setting, every DCR, every alert rule you create by clicking through the Azure portal is a configuration that can drift, get deleted accidentally, or not get applied to new resources. Use Azure Policy with built-in initiative "Enable Azure Monitor for VMs" to automatically deploy the agent and DCRs to any VM in scope. For alert rules, manage them through Bicep or ARM templates in your infrastructure repo, so they're version-controlled and deployed consistently across environments.
Tag your Log Analytics workspace resources deliberately. As your Azure Monitor estate grows, you'll thank yourself for consistent tagging. Tag workspaces with environment: prod, team: platform, and costcenter: xxxx from day one. This makes cost attribution in Azure Cost Management accurate and saves uncomfortable conversations with finance later.
Set up workspace-level data caps to prevent bill shock. In your Log Analytics workspace, go to Settings > Usage and estimated costs and configure a daily volume cap. I recommend setting it at 120% of your expected daily ingestion as a safety net. Yes, it will stop data collection if hit, but a temporary data gap is better than a surprise $50,000 invoice from a misconfigured verbose logging tier suddenly dumping terabytes of debug data into your workspace.
Test alert action groups quarterly. Alert rules sit dormant for months and the action group webhook URL, Logic App, or email distribution list quietly becomes invalid. Build a quarterly calendar reminder to use the Test action group button on every production alert action group. Five minutes of testing prevents the scenario where your on-call engineer doesn't get paged during a real outage.
Migrate off the legacy MMA/OMS agent now. If you have any virtual machines still running the legacy Log Analytics agent, migration to Azure Monitor Agent should be on your roadmap for this quarter, not someday. The old agent's support lifecycle is ending, and the new agent has better performance, DCR-based customization, and support for OpenTelemetry metrics that the old one never will. Microsoft's official migration guide walks you through it resource by resource.
- Assign the built-in Azure Policy "Configure diagnostic settings for Activity Log to Log Analytics workspace" at the subscription level immediately, this catches all control-plane events with zero per-resource configuration.
- Enable Log Analytics Workspace Insights (under your workspace's Monitoring section) for a built-in health dashboard showing ingestion trends, query performance, and agent connectivity, all without writing a single KQL line.
- Use the Azure Monitor Overview dashboard in the portal as your daily operational starting point; it consolidates health signals across applications, VMs, and containers in one view without needing custom workbooks built first.
- For Application Insights, switch all apps from instrumentation key to connection string before your next deployment cycle, it's a one-line config change that future-proofs your telemetry pipeline against upcoming SDK changes.
Frequently Asked Questions
What exactly is Azure Monitor and what can it monitor?
Azure Monitor is Microsoft's unified observability service that collects, analyzes, and acts on telemetry from cloud and hybrid environments. It can monitor pretty much everything in your Azure footprint, virtual machines, Kubernetes clusters, web applications, databases, networking infrastructure, storage accounts, and more. It also extends to on-premises servers and multi-cloud resources through Azure Arc. The service brings together metrics, logs, traces, and events into a single platform so you don't need separate tools for each infrastructure layer. Beyond just collection, it also handles alerting, autoscaling triggers, and visualization through workbooks, dashboards, and Grafana integrations.
How does Azure Monitor actually collect data from my resources?
Data collection in Azure Monitor happens through several distinct pathways depending on the source. For Azure platform resources (like storage accounts, Key Vault, or Azure SQL), you configure Diagnostic Settings to push platform metrics and logs to a Log Analytics workspace. For virtual machines and Arc-connected servers, you install the Azure Monitor Agent and define Data Collection Rules (DCRs) that specify what data to collect and where to send it. For application telemetry, Application Insights uses SDK instrumentation or OpenTelemetry auto-instrumentation in your application code. Prometheus metrics from Kubernetes come through the Azure Monitor managed service for Prometheus into an Azure Monitor workspace. Each pathway is configured independently, which is why partial setup leads to partial visibility.
Why is my Log Analytics workspace showing no data even though resources are configured?
The most common culprits are either a missing Data Collection Rule association or a Diagnostic Setting that was created but pointed to the wrong workspace or subscription. Start by running Heartbeat | take 10 in Log Analytics Logs, if even Heartbeat data is missing, your Azure Monitor Agent either isn't running or isn't associated with this workspace via a DCR. Also double-check that the workspace you're querying is the same one specified in your Diagnostic Settings and DCRs, it's surprisingly easy to have a prod workspace and a dev workspace and be querying the wrong one. Finally, allow at least 10–15 minutes after any configuration change before declaring that data isn't arriving.
What's the difference between a Log Analytics workspace and an Azure Monitor workspace?
These are two different resource types that serve different data types, and confusing them is one of the most common Azure Monitor mistakes I see. A Log Analytics workspace stores log and trace data, think Windows Event Logs, syslog, application logs, and audit trails. You query it with Kusto Query Language (KQL) and it's the destination for Diagnostic Settings and DCR log data. An Azure Monitor workspace, by contrast, stores Prometheus and OpenTelemetry metrics from Kubernetes. You query it with PromQL and visualize it through Grafana. If you're running AKS and wondering why your Prometheus metrics aren't showing up in Log Analytics, it's because they're stored in a completely separate resource. You need both if you're doing both logs and Prometheus-style metrics collection.
How do I monitor AI agents with Azure Monitor?
Application Insights provides built-in monitoring for AI agents running on Microsoft Foundry, Copilot Studio, and third-party agent frameworks. Once your agent workload is instrumented with Application Insights (either through auto-instrumentation or the OpenTelemetry SDK), you get real-time dashboards that surface token consumption, latency, error rates, and quality scores without any custom query writing. Navigate to your Application Insights resource, click AI Agents in the left sidebar if using Foundry, or check the Investigate > Performance and Failures blades for general telemetry. The observability agent feature can also help analyze telemetry, detect anomalies, and correlate signals across data sources when you're troubleshooting generative AI workload issues.
My Azure Monitor alerts are firing too much, how do I reduce alert noise without missing real issues?
Alert noise is one of the fastest ways to erode on-call trust, so this is worth fixing deliberately. Start by using Azure Monitor's AIOps capabilities, dynamic thresholds (available on metric alert rules) use machine learning to set thresholds based on historical patterns rather than fixed numbers, which dramatically reduces false positives for metrics with natural daily or weekly cycles like CPU. For log-based alerts, tighten your KQL query to include more discriminating conditions rather than broad catch-alls. You can also configure Action Rules (under Monitor > Alerts > Action rules) to suppress specific alert rules during maintenance windows, or to merge multiple related alerts into a single notification. The goal is one actionable notification per incident, not one notification per symptom.