Executive Summary The Log Analytics Agent Diagnostics Extension (WAD) The Dependency Agent Summary
The Log Analytics Agent
The Log Analytics Agent is used for collecting guest-level OS metrics, as well as logs. Most Monitoring Solutions also rely on this agent.
This agent is essentially the same as the SCOM Agent, so you can multi-home your SCOM agents to send their monitoring data to their SCOM Management Group as well as a Log Analytics workspace very easily.
Remember: This agent always sends data only to Azure Monitor Logs (Log Analytics workspace). What this means is that this data is available to query in Azure Monitor, but it does not store data as metrics in the Azure metrics database.
For more details, Microsoft covers the difference between Logs and Metrics here.
When to use the Log Analytics Agent:
If you want to collect data from on-prem/non-Azure servers into a workspace. You may be wondering, what about the Azure machines? For Azure machines you’d use “Azure Monitor for VM”, or connect the VM to the workspace (there is a slight difference). Either way, it installs the Log Analytics Agent on them in the process regardless 😊
Manage the security of your virtual machines using Azure Security Center or Azure Sentinel.
Use Azure Automation Update management , Azure Automation State Configuration , or Azure Automation Change Tracking and Inventory to deliver comprehensive management of your Azure VMs.
Monitoring Solutions Diagnostics Extension (WAD)
Alright, pay more attention here because this one’s slightly more complicated. 😉
First off, while the Log Analytics Agent can be installed on any machine, WAD can only be used with Azure VMs. In terms of the data collected, it collects almost the same data as the Log Analytics Agent – guest-level performance, event logs, etc.
You can enable the diagnostic extension for a virtual machine to send platform metrics to other destinations such as Azure metrics, storage account and event hubs.
You can also send some limited data to Azure Monitor Logs (by connecting Storage account to the workspace) , but I wouldn’t really recommend that. If you want to send data to the workspace, better stick to the Log Analytics Agent instead which sends it straight there. Your main tools to view the diagnostics data would be these.
The thing I like about enabling diagnostic settings is the fact that it adds some guest OS metrics to the Metrics database, which can be viewed quickly using the Metric Explorer.
Note that enabling Diagnostics has added another Metric Namespace (Guest classic), under which you now have some guest OS metrics to chart.
I’d re-iterate, this data is only in the metrics database and not available to query in Logs.
Use the Diagnostics extension if:
You want to view the classic guest OS level metrics from the Metric Explorer.
You want to archive your monitoring data (performance and event logs, etc.) for historical purposes by saving it in a Storage Account. Collect
to investigate VM boot issues. Boot Diagnostics
The Dependency Agent
The Dependency Agent discovers data about processes running on the VM and external process dependencies. However, it relies on the Log Analytics Agent to send that data over to the workspace.
The main use of this agent is for the
solution. Service Map
Alright – I realize this is a lot to soak in. I’d also wholeheartedly agree with you if you think this is a bit confusing. So I feel obliged to give you a TL;DR on this one 😉
Luckily, Microsoft has generously done this for us. From
Overview of Azure Monitor Agents:
Once you’ve figured this out, there’s another diagram on a higher level that I find particularly helpful. From
Monitoring Azure virtual machines with Azure Monitor:
Hopefully, this diagram makes a lot more sense to you now!
That’s all about the agents, stay tuned for our next article where we discuss exactly what this “Azure Monitor for VM” is and what it's about.