Azure Monitor Agent is Microsoft's unified telemetry agent for Windows and Linux machines, collecting logs and performance data and routing it to Azure Monitor through centrally managed data collection rules.
Azure Monitor Agent is the telemetry collection component for machines monitored by Azure Monitor. It runs on Windows and Linux servers and reads data sources such as performance counters, Windows event logs, Syslog, and text-based log files. What it gathers, how that data is filtered, and where it is sent are all described in data collection rules that live in Azure rather than in local configuration files. The agent then forwards the records to destinations such as a Log Analytics workspace. Its purpose is to give one consistent, centrally governed way to bring machine telemetry into Azure Monitor across cloud, on-premises, and hybrid fleets.
Context matters here, because the agent is a migration destination rather than a simple addition. It supersedes the legacy Log Analytics agent and the Diagnostics extension for most collection scenarios, so teams usually adopt it while retiring older agents, which means planning rule design, workspace structure, and policy assignment before rollout begins. Deployments increasingly reach beyond Azure through Azure Arc, and platform teams often meet unrelated legacy prerequisites on the same ageing servers, such as the 16-Bit InstallShield Support Package required by very old setup programs on 64-bit Windows. None of that changes the agent's own requirements, but it explains why onboarding ancient hardware takes far longer than onboarding a fresh virtual machine.
Consolidating on Azure Monitor Agent pays off in day-to-day operations. One agent per machine means fewer processes competing for resources and fewer components to patch, which eases both performance planning and compliance reporting. Because collection is defined in rules stored in Azure, changes are reviewable and reversible: a noisy counter can be dropped, a new log path added, or a workspace destination swapped without editing files across hundreds of servers or restarting anything by hand. Managed identity authentication removes shared keys from deployment scripts and machine images, tightening the security story that often slows monitoring projects down. Multi-homing lets security, operations, and application teams each receive the data they need from a single installation. Built-in health signals answer the question that matters most during an outage, namely whether the agent, the rule, or the network is responsible. Add Azure Policy enforcement and hybrid coverage through Arc, and monitoring becomes something the platform guarantees for every new server rather than something engineers remember to configure.
Key capabilities and highlights.
Azure Monitor Agent replaces the collection role of the older Log Analytics and Diagnostics agents with a single installable component that runs on both Windows and Linux machines. Administrators learn one deployment method, one configuration model, and one troubleshooting workflow instead of maintaining separate tooling for each operating system family.
Everything Azure Monitor Agent collects is defined in a data collection rule rather than in workspace settings or local configuration files. Each rule specifies the data sources to read, any transformation to apply, and the destination, so monitoring policy becomes a versioned Azure resource that can be reviewed, reused, and audited like any other deployment artefact.
The agent installs as a virtual machine extension, so it can be rolled out through the Azure portal, PowerShell, the command line, ARM or Bicep templates, Terraform, and Azure Policy. Large estates can enforce installation by policy, letting newly created machines pick up monitoring automatically without anyone running a manual step.
Servers hosted outside Azure can run the same agent once they are connected through Azure Arc, covering on-premises hardware, other public clouds, and edge locations. That consistency means one monitoring pipeline spans a hybrid estate rather than forcing teams to run separate vendor-specific tooling for each environment they operate.
The agent authenticates with a managed identity or service principal rather than the shared workspace key used by older agents. There are no secrets to distribute, rotate, or accidentally expose in scripts, which simplifies security reviews and reduces the risk that a leaked key grants write access to your monitoring data.
A single rule can send collected data to more than one destination, including Log Analytics workspaces and Azure Monitor metrics where that data type is supported. Teams running separate workspaces for security, operations, or individual business units can feed several of them at once without installing additional agents on the same server.
Data collection rules support KQL transformation queries that filter, rename, and reshape records before they are stored. Dropping noisy events or normalising fields at ingestion lowers workspace costs and keeps queries simpler, while sensitive columns can be excluded entirely before the data ever leaves the machine.
Agent health issues, configuration errors, and connectivity problems surface in Azure Monitor alongside dedicated troubleshooting tooling for the agent and its rules. Instead of guessing why a machine stopped reporting data, engineers can quickly confirm whether the extension, the rule association, or a network path is at fault.
Browse historical releases and previous builds.
Common questions about Azure Monitor Agent.
It collects telemetry from Windows and Linux machines and delivers it to Azure Monitor. Typical data includes performance counters, Windows event logs, Syslog messages, and text-based log files. What is collected and where it goes is defined in data collection rules, so the same agent can serve very different monitoring scenarios.
It runs on Windows Server versions and on common Linux distributions, including those running in Azure and outside it. Because the same component covers both families, you can standardise collection across a mixed server estate instead of maintaining separate agents and separate configuration for each platform.
The older agent tied most configuration to the workspace and used a shared workspace key. This agent uses data collection rules stored as Azure resources and authenticates with a managed identity, which makes collection easier to scope, review, and secure. It is also the agent Microsoft positions for current and future monitoring workloads.
Yes. On-premises machines and servers in other clouds can run the agent once they are connected through Azure Arc-enabled servers. From the monitoring side they are then managed with the same rules, policies, and portal experiences as Azure virtual machines, which is what makes a genuinely hybrid monitoring strategy practical.
For log data, yes, a workspace is the usual destination and where you query the collected records. Certain performance data can also be routed to Azure Monitor metrics. Either way, the destination is declared in the data collection rule rather than assumed by the agent.
Most organisations use Azure Policy to install the extension automatically, then associate data collection rules at scale. Templates such as ARM, Bicep, and Terraform, along with the CLI and portal, all handle the same extension, so rollout can be automated as part of an existing infrastructure-as-code pipeline.
No. It replaces the legacy agents for most machine-level log and performance collection, but some scenarios still rely on specialised extensions or the containerised variant used for container monitoring. Check the requirements of each workload before removing anything that is still actively collecting data.
Start with agent health signals in Azure Monitor and the dedicated troubleshooting tools for the agent and its rules. Confirm the extension is installed and running, that the correct data collection rule is associated with the machine, and that required network endpoints are reachable. Those three checks explain most gaps in incoming data.
Azure Monitor Agent is Microsoft's unified telemetry agent for Windows and Linux machines, collecting logs and performance data and routing it to Azure Monitor through centrally managed data collection rules.
Azure Media Services Explorer is a free Windows desktop client for managing Azure Media Services accounts, letting you upload, encode, protect and stream media assets through a graphical interface instead of SDK code.
Microsoft Azure CLI is a command-line tool for creating, configuring, inspecting, and automating Azure resources through interactive commands or reusable scripts, making cloud administration easier to repeat and integrate into operational workflows.
TeamMate is a Windows desktop client for Microsoft Azure DevOps that keeps work items, bugs, and pull requests in one place. It lets developers search, filter, and get notified about changes without opening a browser tab.
Microsoft Azure Storage Explorer is a graphical application for browsing and managing Azure blobs, file shares, queues, tables, and Data Lake resources without relying on command-line storage operations.
Comments