Azure Monitoring: A Complete Guide to Setup & Configuration

When Microsoft launched Azure over 17 years ago, few could have predicted its transformation from a modest experiment into a $70 billion revenue powerhouse. Back then, Microsoft's identity was synonymous with Windowsת packaged software was king, and the cloud was just a strategic hedge against an uncertain future.

Today, Azure has become Microsoft's crown jewel, accounting for roughly 40% of the company's total revenue and growing exponentially, fueled by the global AI boom. But this success story comes with a catch: managing cloud costs at this scale has become a critical challenge for organizations worldwide.

Microsoft offers native cost management tools within Azure, but they're underwhelming.

The reason is painfully obvious: what incentive does Microsoft have to help customers spend less on their platform?

The imperative for Azure Monitor

If you're not already monitoring your Azure environment, you're flying blind.

Cloud spend has evolved from a minor line item to one of the top three expense categories for most organizations, often surpassed only by payroll.

Yet unlike traditional expenses that receive rigorous oversight, cloud costs frequently slip through the cracks, unmonitored, misunderstood, and growing unchecked.

The challenge goes beyond simple expense tracking. In cloud environments, attributing costs to specific services, teams, or projects becomes a complex puzzle. Shared resources, cross-functional workloads, and elastic scaling create a financial opacity that traditional budgeting tools can't penetrate. Without proper monitoring, cloud costs become uniquely slippery, difficult to predict, harder to control, and nearly impossible to govern effectively.

Understanding Azure Monitor

As the second-largest cloud provider after AWS, Microsoft has developed Azure Monitor as its comprehensive monitoring solution. This platform serves as the central nervous system for your Azure environment, collecting and analyzing data from every layer of your infrastructure to maximize application performance and service reliability.

Azure Monitor operates on a simple but powerful principle: aggregate all monitoring data into a common platform where it can be correlated, analyzed, and acted upon. Whether you're running workloads in Azure, other clouds, or on-premises, the platform provides unified visibility across your entire estate.

What Azure Monitor can track

The platform's monitoring capabilities extend across:

1. Applications
2. Virtual machines
3. Guest operating systems
4. Containers including Prometheus metrics
5. Databases
6. Security events in combination with Azure Sentinel
7. Networking events and health in combination with Network Watcher
8. Custom sources that use the APIs to get data into Azure Monitor

The two pillars of monitoring data

Azure Monitor fundamentally deals with two types of data:

1. Metrics: light weight data, time sensitive, that depicts a certain asset in a specific time, such as CPU usage.They are ideal for real-time monitoring, and identifies abnormal patterns. The metrics are stored in a data set organized by time, that enables fast queries. 
2. Logs: detailed events that describe actions, errors, and other events in the system, such as security events/ These logs are often used for RCA, investigating security errors and a depth analysis of usage patterns. The logs are stored in Log Analytics Workspaces,based on Azure Data Explorer.

‍

Setup and configuration

Setting up Azure Monitoring properly requires systematic planning and execution:

Plan a monitoring strategy 

Start by deciding what you actually want to monitor, not because you can track everything, but because you shouldn’t. Focus on the resources that matter most to your environment, and define clear KPIs around them: application response times, service availability, resource utilization. Set alert thresholds that are meaningful, not too sensitive to every fluctuation, but early enough to catch real issues before they escalate.

Assign responsibilities so it’s clear who’s watching the data and who’s expected to act when something looks off. Good monitoring only works when someone’s paying attention. And don’t forget the budget, storing and analyzing logs over time can add up. It’s worth estimating how much data you’ll generate and where you’re comfortable investing for visibility versus simply retaining for compliance.

Enable diagnostic settings

Azure Monitor doesn’t collect detailed data by default, it waits for instructions. That means you’ll need to enable diagnostic settings for each resource you want to track. This includes Load Balancers, Virtual Network Gateways, Key Vaults, Storage Accounts, anything you’d want to understand better when things go wrong.

Within the Azure portal, go to each resource, open the “Diagnostic settings” section, and choose which logs and metrics to collect. Then configure where that data should go. A Log Analytics Workspace gives you querying power and alerting flexibility. A Storage Account offers low-cost long-term retention. Event Hubs can forward data into other systems in real time. Choose based on how you want to consume the information, or where others in the organization need to access it.

It may feel like a lot of setup, but it’s what turns a black box into something you can reason about. And when production starts acting up, having that visibility in place is the difference between guessing and knowing.

Set up Log Analytics Workspaces:

If you want to do anything meaningful with logs in Azure, beyond just knowing that something happened, somewhere, at some point, you'll need a Log Analytics Workspace. It’s where logs and metrics from various sources come together: diagnostic settings, agents, platform telemetry, and more. Once the data is there, you can query it using KQL (Kusto Query Language), which is surprisingly powerful, assuming you enjoy writing SQL-like queries with just enough quirks to make it interesting.

You’ll usually want to create one workspace per region or logical app group, it keeps things clean and avoids surprises later. After that, connect the relevant resources. This includes virtual machines, which can report data through either the classic Log Analytics agent or the newer Azure Monitor agent, depending on what generation of deployment you’re working with (or inherited). Once everything is connected, the workspace becomes your main point of insight, a place where raw telemetry becomes something you can actually work with.

Add Application Insights (for APM monitoring):

Application Insights is an APM tool, that’s Application Performance Management, not another cloud acronym to ignore. It gives you visibility into how your application is behaving in the real world: response times, server calls, exceptions, dependencies, even what’s happening in users’ browsers. It’s built to help you catch issues before they become support tickets, and to understand what’s actually going on when someone says, "the app feels slow."

Setting it up is straightforward. You can link Application Insights directly to your resource, for example, an Azure Web App, and choose how deep you want to go. If you want full control, integrate the SDK into your code. If you'd rather not touch the code at all (understandable), use autoinstrumentation, particularly convenient if you’re running in Azure App Services. One toggle, and telemetry starts flowing.

Install Agents on Virtual Machines (VMs):

Azure gives you a couple of options when it comes to collecting telemetry from virtual machines. The Azure Monitor Agent (AMA) is the modern, recommended choice. It works across Windows and Linux VMs, whether they’re in your main Azure regions or somewhere more exotic. It’s more flexible than its predecessor, letting you choose exactly what data gets sent where — for example, to Log Analytics for querying or to Azure Monitor Metrics for visualization.

Then there’s the Log Analytics Agent, which is still around, mostly for legacy environments, scripts that haven’t been touched in a while, or that one system no one wants to migrate just yet. It gets the job done but lacks the fine-grained control and future support you get with AMA.

Both agents collect similar types of data: event logs, performance counters, and system metrics directly from the guest OS. The difference is mostly in how much control you want, and whether you're planning for the long term.

Optimization and best practices

Optimizing Azure Monitoring is critical to controlling costs, minimizing noise, and improving effectiveness.

Data collection optimization

Collecting data is easy, but collecting only what you actually need, that takes a bit more thought. Azure makes it simple to turn on diagnostics and send logs everywhere, but over-collecting can quickly lead to noise, cost, and dashboards no one looks at.

Start by reviewing your Diagnostic Settings and selecting only the log categories that are relevant to your use case. If a log doesn’t help you monitor, troubleshoot, or analyze behavior, it probably doesn’t need to be collected.

In Application Insights, use sampling to limit the volume of telemetry from high-traffic applications. You can also configure filters at the agent or app level to avoid sending logs that add little value, like heartbeat pings or repetitive traces.

Finally, set a clear data retention policy. Not all logs need to live forever in your Log Analytics Workspace. For older data that’s rarely queried but still needs to be kept, consider archiving it to a Storage Account, much cheaper, and still accessible when needed.

Set Smart Alerts and Actions:

Not all alerts are created equal, and the fastest way to get people to ignore them is by sending too many, too often, for things that don’t matter. Instead of using fixed, generic thresholds, take the time to understand your resource behavior. Azure Monitor supports dynamic and baseline-based thresholds, using built-in machine learning to adjust to real patterns. It’s a good way to reduce false positives and avoid the dreaded alert fatigue.

There are a few types of alerts you’ll likely use:

• Metric Alerts trigger when a numeric value crosses a defined threshold, for example, CPU usage above 80% for more than 5 minutes.
• Log Alerts run on top of KQL queries in Log Analytics, and are great for catching patterns or critical errors buried in logs.
  Activity Log Alerts notify you when important actions happen in Azure, like someone deleting a resource they really shouldn’t have.

To make alerts useful, attach Action Groups. These define what happens when an alert fires:
You can notify people via email, SMS, or push notifications through the Azure app. Or take it a step further and automate the response, trigger a runbook in Azure Automation, send a webhook (to Slack, Teams, or wherever your ops team lives), or even open a ticket automatically in your ITSM system. The idea is to close the loop quickly, preferably before anyone notices something’s wrong.

Visualize what matters

Once you’ve got telemetry flowing, the next step is making sense of it, preferably without scrolling through raw logs at 2am. Azure gives you a few solid tools for that.

Dashboards in the Azure portal let you build custom views of your environment, graphs, KPIs, charts, all in one place. It’s a clean, visual way to keep an eye on what matters most, whether it's CPU usage, request counts, or error rates. These are great for at-a-glance monitoring and sharing with teams.

For deeper dives, Workbooks offer more flexibility. They combine KQL queries, metrics, text, and visualizations into interactive reports. Think of them as a mix between a dashboard and a notebook, perfect for troubleshooting, documenting an incident, or exploring performance trends over time. And if you’re already in Log Analytics, you can create custom views directly within the workspace. These give you quick, focused ways to explore the logs you care about, without writing the same queries over and over again.

Keep an eye on cost

Monitoring is essential, but so is making sure your monitoring setup doesn’t quietly drain your budget. Azure gives you the tools to track and control costs, but they don’t help much unless you actually use them.

Start with Azure Cost Management. It lets you track how much you're spending on Azure Monitor, set budgets, and create alerts when things start creeping past your limits. It won’t stop the charges, but at least you won’t be surprised by them.

Next, review your Log Analytics pricing tier. Azure offers different plans, like Pay-as-you-go (Per GB) or Capacity Reservations, depending on how predictable your workload is. If you’re sending a lot of data on a regular basis, reservations can offer real savings. If your usage is lighter or inconsistent, per-GB pricing might be simpler.

‍

Finally, think about log retention. Not all data needs to live in your workspace forever. For older logs that aren’t part of your day-to-day analysis but still need to be retained, consider moving them to lower-cost storage using Log Archive. It’s cheaper, and it keeps your workspace clean and efficient.

Integration with third-party tools:

Azure Monitor provides integration with many monitoring and SIEM tools through Event Hubs, Webhooks, and APIs, allowing you to stream data to existing systems in your organization.

Automation with Azure Automation and Logic Apps

Use Azure Automation Runbooks or Azure Logic Apps to automatically respond to alerts, for example, running scripts to fix issues, scaling resources, or creating events in ITSM systems.

‍