Azure Monitor: Eyes and Ears for Everything You Run in the Cloud
A beginner-friendly guide to Azure Monitor, the service that collects numbers, logs and traces from your applications and infrastructure, helps you understand what is happening, and warns you before small problems become big ones, explained step by step with everyday analogies.
Imagine you are the captain of a huge ship. You cannot see the engine room, the cargo hold or the weather ahead with your own eyes. So the ship has gauges for speed and fuel, a logbook that records everything that happens, radar that watches for danger, and alarms that ring when something goes wrong. Without them you would be sailing blind and would learn about a problem only when water reached the deck. Azure Monitor is the gauges, the logbook, the radar and the alarms for your cloud systems.
In this guide we begin with the simple question “what does it mean to monitor something?”, and slowly build up to metrics, logs, traces, alerts, dashboards, cost and good habits. No earlier knowledge is needed. Every new word is explained when it first appears.
1What Is Azure Monitor?
Azure Monitor is Microsoft’s platform for collecting, analysing and acting on information from your cloud and on-premises systems.
Every running system produces information about itself. A web server records each request it receives. A virtual machine reports how busy its processor is. A database notes how long each query took. This information is called telemetry, which simply means measurements sent from a distance. Telemetry is valuable, but only if somebody collects it, stores it, searches it and reacts to it.
Azure Monitor does all of these jobs. It gathers telemetry from Azure resources automatically, and from your own applications, servers and containers when you ask it to. It stores the data in purpose-built stores, gives you tools to explore it, draws charts and dashboards, and sends alerts when something looks wrong. It can even take automatic action, such as adding more servers when traffic grows.
Monitoring is not the same as fixing. Azure Monitor tells you what is happening and where, so that people or automation can decide what to do. A clear picture of the system is the first step towards reliability.
Think of the dashboard of a car. The speedometer and fuel gauge show numbers right now, the trip computer remembers what happened over the journey, and warning lights flash when the engine overheats. Azure Monitor is a dashboard for your whole fleet of cloud systems, with a memory that goes back months.
Words you will meet again and again
Telemetry
The measurements, records and events that systems send out about their own behaviour.
Metric
A number measured at regular intervals, such as processor percentage once a minute.
Log
A text record of an event, with details such as time, source and message.
Trace
The recorded path of a single request as it travels through several services.
Alert
An automatic notification or action that fires when a condition becomes true.
Log Analytics Workspace
The storage and query home for logs, where you search the data using a query language.
2Why Do We Need Monitoring?
Because systems fail in surprising ways, and the cost of finding out late is high.
A shop that opens at nine can see at once if the lights are off. A cloud system has no such obvious signs. A website may be slow for half the visitors, an order service may fail only on Tuesdays, and a database may be quietly running out of space. If nobody is watching, the first sign of trouble is an angry customer.
Monitoring changes this. It lets you notice problems early, find their cause quickly, prove that you meet promises to customers, plan for growth and spot waste. In large companies, a few minutes of downtime can cost a great deal of money, so quick detection and fast diagnosis are worth a lot.
Detect problems early
Alerts tell you about a failing service within minutes, often before users notice.
Diagnose faster
When something breaks, logs and traces show where and why, so engineers do not have to guess.
Understand usage
Metrics reveal how many people use a feature, when traffic peaks and which parts are slow.
Plan capacity and control cost
Trends show when to add power and when resources are sitting idle and wasting money.
Prove reliability
Historical data supports service-level promises and helps with audits and post-incident reviews.
You will often hear the word observability. Monitoring asks known questions, such as “is the processor above ninety percent?”. Observability means having enough rich data, such as logs and traces, to answer questions you did not think of in advance. Azure Monitor supports both.
3The Pillars: Metrics, Logs, Traces and Changes
Different questions need different kinds of data, and Azure Monitor handles each kind in the best way.
Metrics
Light numbers measured at regular intervals. Fast to read, great for charts, thresholds and quick alerts.
Logs
Detailed records of events. Slower and larger than metrics, but rich enough to answer deep questions.
Traces
The journey of one request across many components, showing where time was spent or where failure occurred.
Changes
Records of what was changed, such as a configuration edit or a new deployment, which often explain a sudden problem.
| Feature | Metrics | Logs | Traces |
|---|---|---|---|
| What it holds | Numbers over time | Detailed event records | Request paths with timings |
| Speed to query | Very fast, near real time | Fast, but depends on the query | Fast for single requests |
| Best question | How is it doing right now? | What exactly happened? | Where did this request slow down? |
| Typical use | Dashboards and threshold alerts | Investigation, audits and pattern searches | Finding the slow or failing step in a chain |
| Cost pattern | Platform metrics are free | Charged by volume ingested and kept | Charged as part of application telemetry |
When a child is unwell, a thermometer reading is a metric: quick and simple. A doctor’s notes about symptoms over the week are logs: detailed and descriptive. Following the child’s path through reception, X-ray and pharmacy to see where the long wait occurred is a trace.
Using logs for everything. Logs are powerful but expensive in storage and slower to query. Use metrics for live health and alerts, and keep logs for detail and investigation.
4Sources and the Big Picture
Azure Monitor collects information from many layers of your environment.
Think of your environment as a stack of layers. At the top sit your applications, where code runs. Below are the operating systems of servers and containers. Below that are the Azure resources, such as databases and storage accounts. Further down is the Azure subscription, where management actions occur, and at the bottom is the Microsoft Entra tenant, which handles identities. Azure Monitor can collect data from every layer.
Application layer
Requests, errors, dependencies, performance and custom events from your own code, collected through Application Insights.
Guest operating system layer
Processor, memory, disk, event logs and files inside virtual machines and servers, collected through an agent.
Azure resource layer
Health and behaviour of each Azure service, through platform metrics and resource logs.
Subscription layer
The Activity Log, which records who created, changed or deleted resources.
Tenant layer
Sign-in and audit logs from Microsoft Entra ID, showing who accessed what.
flowchart LR
A["Applications"] --> M["Azure Monitor"]
B["Virtual Machines and Containers"] --> M
C["Azure Resources"] --> M
D["Subscription and Tenant Logs"] --> M
M --> E["Metrics Store"]
M --> F["Log Analytics Workspace"]
E --> G["Dashboards and Alerts"]
F --> G
G --> H["People and Automation"]
A big hospital collects information from the patient’s bedside machine, the ward records, the building’s power system and the visitors’ register. A central control room puts it all together so staff can see the whole picture at once.
5Metrics in Depth
Metrics are the simplest and fastest way to know how healthy something is.
A metric is a number with a time stamp and a name, such as “processor percentage at 10:01 is 42”. Azure collects platform metrics for most resources automatically, with no setup and no charge. They are stored in a special time-series database that is built for fast reading of numbers over time. Platform metrics are kept for about three months, which is enough for most day-to-day questions.
Dimensions
Labels attached to a metric, such as the name of a server or the status code of a request. They let you split one metric into many lines on a chart.
Aggregation
The way values are combined over a time period: average, minimum, maximum, sum or count. Choosing the right one changes the story.
Granularity
How often the points are shown, such as every minute or every hour. Shorter intervals show spikes; longer ones show trends.
Custom Metrics
Your own numbers, such as orders per minute, sent from your application so that they sit next to platform metrics.
Imagine measuring the temperature of a room every minute. The average over an hour hides a short hot spike, while the maximum shows it. Both are true, but they answer different questions, so you must choose the aggregation that matches your worry.
Metrics Explorer
A tool in the portal where you pick a resource and a metric, draw it as a chart, split it by dimension, compare it with another metric and pin it to a dashboard.
Near real-time alerts
Because metrics are quick to read, they are the best choice for alerts that must fire within a minute or two.
Managed Prometheus
For container platforms such as Kubernetes, Azure Monitor offers a managed version of Prometheus, an open-source metrics system, so teams can use familiar tools without running the servers themselves.
Alerting on the average of a metric when users suffer from the worst cases. A web page with an average response of one second may still take ten seconds for a few percent of users. Look at high percentiles and maximums for latency questions.
6Logs, Log Analytics and the Query Language
Logs hold the detailed story, and Log Analytics is where you read it.
A log entry is a record with fields such as the time, the source, the severity and a message. Azure Monitor Logs stores these records in a Log Analytics workspace. A workspace organises records into tables, much like a database. There is a table for virtual machine events, another for requests to your website, another for security sign-ins, and so on.
To search the tables you use the Kusto Query Language, shortened to KQL. KQL reads like a pipeline. You start with a table, then pass the rows through a series of steps, each one filtering, adding columns, grouping or sorting. The language is designed to be easy to read from left to right, and it is very fast on huge amounts of data.
Start with a table
Name the table that holds the records you want, such as the one for web requests.
Filter
Keep only the rows that matter, such as errors in the last hour. Filtering early makes queries faster and cheaper.
Summarise
Group rows and calculate counts or averages, for example errors per minute per server.
Shape and sort
Choose the columns to show, sort the result and limit the number of rows.
Visualise or alert
Turn the result into a chart, a dashboard tile or an alert rule.
Searching logs with KQL is like standing at a conveyor belt of paper records. At each station along the belt, a worker removes pages you do not need, stamps extra notes on others, or counts them into piles. What reaches the end of the belt is the answer.
Table plans and retention
| Plan | Best for | Query abilities | Cost level |
|---|---|---|---|
| Analytics | Data you query and alert on often | Full KQL, alerts, dashboards | Highest per gigabyte |
| Basic | High-volume, low-value data such as verbose debug logs | Simpler queries, limited features | Lower ingestion cost, query charges apply |
| Auxiliary | Very high-volume data kept for compliance and rare searches | Basic search only | Lowest ingestion cost |
Data stays immediately queryable for a configurable retention period, which by default is a short number of weeks. You can keep data much longer in a cheaper long-term state, for years where compliance needs it, and search it later when needed.
Not all data deserves the same treatment. Keep important, often-queried data in the Analytics plan, move noisy debug data to cheaper plans, and set retention to match legal and business needs rather than keeping everything forever by default.
7Activity Log, Resource Logs and Diagnostic Settings
Some data arrives by itself, and some needs you to switch it on.
Platform Metrics
Collected automatically for almost every Azure resource, free of charge.
Activity Log
Collected automatically. Records management operations such as creating, updating or deleting a resource, and who did it. Kept for about ninety days unless you send it elsewhere.
Resource Logs
Detailed records of operations inside a service, such as each request to a storage account. Not collected until you create a diagnostic setting.
Diagnostic settings: the routing switch
A diagnostic setting tells a resource where to send its logs and metrics. Each resource can send data to one or several destinations. You choose which categories of data to send and where.
Log Analytics workspace
For searching with KQL, creating alerts and building workbooks.
Storage account
For cheap, long-term archive, such as keeping audit records for many years.
Event Hubs
For streaming data to external tools, such as a security system or a third-party monitoring product.
Partner solutions
For sending data directly to certain external monitoring partners.
Every shop keeps a till receipt roll, but the roll just sits inside the machine. A diagnostic setting is the instruction “photocopy every receipt and send one copy to the accountant, one to the archive room and one to the head office”.
Assuming that resource logs exist because the resource exists. Until a diagnostic setting is created, detailed logs are simply not stored, and you cannot investigate an incident afterwards. Enable diagnostic settings early, ideally through policy, so that new resources are covered automatically.
8Agents and Data Collection Rules
To see inside a server, you need a small program running on it.
Azure resources report their own health from the outside. But what happens inside a virtual machine, such as how much memory the operating system uses or which errors appear in its event log, is invisible from outside. For that, Azure Monitor uses the Azure Monitor Agent, a small program installed on the machine. It replaces older agents, which have been retired, so new work should use this one.
The agent does not decide on its own what to collect. You describe that in a data collection rule, often shortened to DCR. A rule says which data to collect, how to change it on the way, and where to send it. One rule can be attached to many machines, so that hundreds of servers follow the same instructions.
Install the agent
The agent is added to servers as an extension, or automatically through policy.
Create a data collection rule
Choose the data sources, such as performance counters and system events, and the destination workspace.
Associate the rule
Link the rule to machines or groups of machines, so the agent knows which instructions to follow.
Transform on the way
Optionally filter out noisy records or remove unneeded columns before storage, which cuts cost.
Data arrives
Records flow into the chosen tables and can be queried within a short time.
The agent is a reporter placed inside each office building. The data collection rule is the assignment sheet that tells the reporter which events to cover, what to leave out and which newsroom to send the story to.
Use the filtering ability of data collection rules to drop low-value records, such as repeated informational messages, before they are stored. Money saved here is saved on every gigabyte, every month.
Collecting every available counter and every log from every machine “just in case”. The bill grows quickly and the useful signals are buried in noise. Decide what questions you need answered, and collect data to answer them.
9Application Insights: Watching Your Code
Application Insights is the part of Azure Monitor that understands your own software.
Infrastructure metrics tell you that a server is busy. They do not tell you that the checkout page throws an error when a customer uses a certain coupon. Application Insights answers such questions. It collects information from inside your application, such as every request, every dependency call to a database or another service, every exception and the time each one took.
Application Map
Draws a picture of your application’s components and the calls between them, with health and speed on each line. Slow or failing links stand out at once.
Transaction Search and End-to-End Tracing
Follows a single request through all the services it touched, showing time spent in each step.
Failures and Performance Views
Group errors and slow operations, so you fix the problems that affect the most users first.
Live Metrics
Shows what is happening right now, with a delay of about a second, useful during a release or incident.
Availability Tests
Probe your website or API from several locations around the world on a schedule, and alert if it stops responding.
Smart Detection
Automatic alerts about unusual changes, such as a sudden rise in failures or slow responses, without you setting thresholds.
How data is collected
Applications send data using instrumentation, which is code or an agent that records telemetry. Microsoft now recommends distributions based on OpenTelemetry, an open standard for telemetry, so that the same instrumentation works across vendors. For many popular platforms, you can switch on monitoring with little or no code change. Application Insights stores its data in a Log Analytics workspace, so you can query it with KQL alongside infrastructure logs.
Infrastructure monitoring tells you that the restaurant’s kitchen is hot and busy. Application Insights is the waiter’s notebook that records which dish, at which table, took forty minutes and why. Both views are useful, and together they tell the whole story.
For very busy applications, keeping every telemetry record is costly. Sampling keeps a representative percentage and still gives accurate statistics. Adjust it to balance detail against cost, and never sample away errors you care about.
Writing personal or secret data into telemetry, such as full names, card numbers or passwords inside log messages. Telemetry is widely visible to engineers and kept for months. Scrub sensitive fields before they leave the application.
10Insights: Ready-Made Monitoring for Common Resources
For common resource types, Azure Monitor offers curated experiences that work out of the box.
Collecting data is only the first step. Making sense of it takes time. To save effort, Azure Monitor provides insights, which are pre-built monitoring experiences for particular kinds of resources. Each one gathers the right data, shows ready-made charts and gives you a good starting set of views for that type of resource.
VM Insights
Shows performance trends of virtual machines and the connections between them, including processes and dependencies.
Container Insights
Monitors Kubernetes clusters and containers, showing node health, pod behaviour and logs.
Storage and Database Insights
Show capacity, latency, transactions and error rates for storage accounts and several database services.
Network Insights
Gives a topology view and health of network resources, with links to connectivity diagnostics.
Why they help
They save weeks of building dashboards, apply good practice by default and give new team members an instantly useful starting point.
Where to look first
Open the insight for a resource type, find the unhealthy item, then drill down into metrics and logs for the detail.
A general medical test gives raw numbers. A cardiology report gives the same kind of numbers already arranged and explained for the heart. Insights are the specialist reports for each type of resource.
Many teams like Grafana for dashboards. Azure offers a managed Grafana service that connects to Azure Monitor and Prometheus data, so you can keep familiar dashboards without running the servers yourself.
11Alerts and Action Groups
Data is useful only if someone acts on it, and alerts make sure someone does.
An alert rule watches a source of data and fires when a condition becomes true. When it fires, it triggers an action group, which is a reusable list of people to notify and automated actions to run. Separating the rule from the action group means that you can write many rules and send them all to the same on-call team.
Metric Alerts
Watch a numeric value, such as processor percentage over a threshold. Fast and reliable, they can react within a minute.
Log Search Alerts
Run a KQL query on a schedule and fire when the result meets a condition, such as more than fifty errors in ten minutes.
Activity Log Alerts
Fire when a management event occurs, such as a resource being deleted or a service health incident being announced.
Smart Detection Alerts
Automatic alerts from Application Insights when it spots unusual patterns in failures or speed.
What action groups can do
Notify people
Send email, text messages, mobile push notifications or voice calls to the right people.
Call other systems
Trigger a webhook, a workflow, a function or a ticketing system, so incidents are created automatically.
Run repairs
Run an automation script that restarts a service or scales a resource, fixing common problems without waking anyone.
Condition becomes true
A metric crosses its threshold or a query returns matching results.
Alert fires
An alert is created, with a severity level and details about what happened.
Processing rules apply
Optional rules can mute alerts during planned maintenance or add extra action groups.
Action group runs
People are notified and automation starts.
Resolution
Many metric alerts resolve automatically once the condition clears, and notify you that the problem has ended.
A smoke detector senses smoke, which is the rule. When it triggers, it rings the alarm, calls the fire brigade and unlocks the doors, which is the action group. You can fit smoke detectors in every room, and all of them can use the same alarm system.
Too many alerts teach people to ignore them. Alert only on conditions that need a human to act, set sensible thresholds, group related alerts and review noisy rules often. An alert that always fires is worse than no alert.
12Workbooks, Dashboards and Visualisation
A good picture makes patterns obvious that rows of numbers hide.
Metrics Explorer Charts
Quick charts of metrics for one or several resources. Ideal for fast investigation.
Azure Dashboards
Boards in the portal where you pin charts and query results from many services side by side.
Workbooks
Interactive reports that mix text, metrics, log queries and parameters. Great for guided investigations and team reports.
Managed Grafana
Rich dashboards for teams that already use Grafana and want one place for many data sources.
Power BI
Business reports built on log data, for people outside the engineering team.
Workbooks for investigations
A workbook can walk someone through steps: pick a subscription, pick a resource, view its health, then drill into failures. New team members can follow the same path every time.
Dashboards for glances
A wall display of key numbers lets the team see at a glance whether everything is healthy.
Reports for stakeholders
Business owners care about orders and sign-ups, not processor load. Build views in their language.
A pilot’s cockpit shows only the instruments needed at a glance, while the flight engineer’s panel has deeper detail for investigation. A dashboard is the cockpit view and a workbook is the engineer’s panel.
Start every dashboard with the question it should answer. Show a few clear signals, such as availability, errors, latency and saturation, rather than dozens of charts that nobody reads.
13Inside the Machine: The Journey of Telemetry
Following one measurement from source to alert shows how all the parts fit.
Generation
A resource, an agent or an application creates a measurement or a record.
Collection
The platform, an agent, a diagnostic setting or an instrumentation library captures it and sends it to Azure Monitor.
Ingestion and transformation
The data reaches the ingestion service, where data collection rules can filter, reshape and route it.
Storage
Numbers go to the metrics database, and records go to tables in a Log Analytics workspace.
Analysis and alerting
Alert rules evaluate the data on a schedule or continuously, and people explore it through charts and queries.
Action and export
Action groups notify and automate, and data can be exported to storage or event streams for other tools.
sequenceDiagram
participant R as Resource or App
participant C as Agent or Diagnostic Setting
participant I as Ingestion Service
participant S as Metrics Store and Workspace
participant A as Alert Rule
participant G as Action Group
R->>C: Produce metric or log record
C->>I: Send telemetry
I->>I: Apply collection rule transformations
I->>S: Store data
A->>S: Evaluate condition
S-->>A: Result meets condition
A->>G: Fire alert
G-->>G: Notify team and run automation
Think of a postal system. A letter is written, collected from a postbox, sorted at a depot, stored in a pigeonhole and finally read by someone who acts on it. Telemetry follows the same journey, with filtering at the sorting depot to avoid delivering junk mail.
Metrics usually appear within a minute or two. Logs may take a few minutes to become searchable. Keep this delay in mind when you design alerts and when you wonder why the newest record is not yet visible.
14Security and Access Control
Monitoring data often contains sensitive details, so access must be controlled.
Role-based access control
Use built-in roles such as monitoring reader, monitoring contributor and log analytics reader, giving each person only what they need.
Workspace access design
Decide whether people see all data in a workspace or only the data of resources they own. Table-level and resource-level controls help limit exposure.
Private connectivity
Use Azure Monitor Private Link Scope to keep telemetry traffic on your private network instead of the public internet.
Encryption
Data is encrypted at rest and in transit, and customer-managed keys are available for dedicated clusters where policy requires them.
Protect the data itself
Keep secrets and personal data out of logs, and use data collection rule transformations to remove sensitive fields before storage.
Audit the auditors
Watch who changes alert rules, diagnostic settings and data retention, because an attacker may try to hide their tracks.
The security camera room of a building holds recordings of everyone’s movements. Only authorised staff may enter, the recordings are locked away, and any attempt to switch off a camera raises its own alarm.
Giving everyone full access to one big workspace. Logs may include customer data, internal addresses and security events. Separate workspaces or use fine-grained access so that people see only what their job requires.
15Understanding and Controlling Cost
Platform metrics are free, but logs can become one of the largest items on an Azure bill.
Log Ingestion
Charged by the amount of data brought into a workspace. Usually the largest part of the cost.
Retention
A free period is included, and longer retention is charged per gigabyte per month.
Alert Rules
Charged per rule and per type, with log alerts and very frequent checks costing more.
Queries on Cheaper Plans
Basic and auxiliary plans charge for the data scanned by queries.
Notifications and Export
Text messages, voice calls and data export carry their own small charges.
Find the biggest tables
Check which tables ingest the most data. A few noisy sources usually cause most of the bill.
Filter at the source
Use data collection rule transformations to drop low-value records and unused columns.
Use the right plan
Move noisy, rarely queried data to cheaper table plans.
Tune retention
Keep data online only as long as you need to query it quickly, and archive the rest cheaply.
Consider commitment tiers
At high daily volumes, a commitment tier gives a lower price per gigabyte than pay-as-you-go.
Set a daily cap and budget alerts
Protect against runaway logging with budgets and alerts. Use a daily cap carefully, since it stops collection when reached and can create blind spots.
Keeping every receipt, every flyer and every wrapper you ever received fills a house with paper. Keeping only the receipts you may need for tax, and shredding the rest, saves space and still protects you.
Turning on verbose debug logging in production and forgetting about it. A single chatty component can multiply ingestion overnight. Review ingestion trends weekly and set alerts on unusual growth.
16Azure Monitor and Its Neighbours
Several Azure services look at health, and each answers a different question.
| Service | Question it answers | Scope |
|---|---|---|
| Azure Monitor | How are my resources and applications behaving, and what happened? | Your own resources, applications and infrastructure |
| Azure Service Health | Is Azure itself having a problem, or planned maintenance, that affects me? | Azure platform events relevant to your subscriptions |
| Resource Health | Is this particular resource healthy from Azure’s point of view? | A single resource |
| Microsoft Defender for Cloud | Is my environment secure, and are there threats? | Security posture and threat protection |
| Microsoft Sentinel | What security incidents need investigation across the whole organisation? | Security operations, built on Log Analytics |
| Azure Advisor | How can I improve cost, reliability, security and performance? | Recommendations for your resources |
| Network Watcher | Why can these two network points not connect? | Network diagnostics |
In a city, the power company announces outages in your area, which is like Service Health. A smart meter in your house shows your own electricity use, which is like Azure Monitor. A home security company watches for burglars, which is like Defender and Sentinel. An energy adviser suggests how to save money, which is like Advisor.
Monitor versus Service Health
If your application slows down, check Service Health first to see whether Azure has a known incident, then use Azure Monitor to look at your own components.
Monitor versus third-party tools
Many companies use other monitoring products as well. Azure Monitor can export data to them, and some tools can read from Azure Monitor, so choices are not all or nothing.
Microsoft Sentinel stores its security data in Log Analytics workspaces, so security and operations teams can sometimes share the same infrastructure, with careful access control.
17Design Patterns That Work Well
These approaches appear again and again in well-monitored systems.
Pattern: The Golden Signals
For every service, watch four signals: latency, traffic, errors and saturation. If these are healthy, users are most likely happy.
Pattern: Central Workspace per Environment
Send logs of one environment, such as production, to a dedicated workspace, so that access, retention and cost can be controlled together.
Pattern: Monitoring as Code
Define alert rules, action groups, diagnostic settings and data collection rules in templates stored in version control, so every environment is monitored consistently.
Pattern: Policy-Driven Coverage
Use Azure Policy to automatically enable diagnostic settings and install agents on new resources, so nothing is forgotten.
Pattern: Tiered Alerts
Critical alerts page the on-call engineer immediately. Warnings go to a chat channel. Informational events go to a dashboard. Everyone knows what each level means.
Pattern: Alert, Diagnose, Act
Each alert links to a workbook or runbook that shows how to diagnose and fix the issue, which shortens response time.
flowchart TD
P["Production Resources"] --> D["Diagnostic Settings and Agents"]
D --> W["Production Workspace"]
W --> AL["Alert Rules"]
AL --> AG["Action Groups"]
AG --> ON["On-call Engineer"]
AG --> CH["Team Chat Channel"]
AG --> TK["Ticketing System"]
W --> WB["Workbooks and Dashboards"]
W --> EX["Archive to Storage"]
18Real-World Examples
Monitoring quietly protects almost every serious cloud system.
Online retail during a sale
Availability tests and failure alerts watch the shop around the clock. When traffic rises, autoscale rules add servers, and a workbook shows the checkout funnel so that the team can fix a payment error within minutes.
Banks and insurers
Audit logs are kept for years in cheap archive storage, access to logs is tightly controlled, and alerts watch for changes to critical settings.
Healthcare systems
Uptime of patient-facing systems is tracked closely, with escalations to on-call engineers, and telemetry is cleaned of personal data before it is stored.
Software-as-a-service vendors
Dashboards show the health of each customer’s environment, and service-level reports use stored metrics to prove uptime promises.
Media and gaming
Live metrics during big launches show load and errors in seconds, and teams scale services before players are affected.
Manufacturing and logistics
Applications that connect factories and delivery fleets are watched through traces, so a slow link between two services can be found and repaired quickly.
Advantages
- Automatic platform metrics and activity logs for most resources
- One platform for metrics, logs, traces and alerts
- Powerful query language and rich visualisation tools
- Deep integration with Azure services and automation
- Flexible export to other tools and long-term storage
Disadvantages / Trade-offs
- Many features and options create a real learning curve
- Log costs can grow quickly without governance
- Detailed logs need deliberate setup, they are not on by default
- Logs have a short delay before they become searchable
- Features and plans evolve, so documentation must be rechecked often
19Anti-Patterns to Avoid
These shortcuts regularly lead to blind spots, alert fatigue and big bills.
Problem
Teams set up alerts on every metric they can find, with tight thresholds, and send them all to one email list.
Why It’s Harmful
People receive hundreds of messages and learn to ignore them. When a real emergency arrives, it is lost in the noise.
Correct Approach
Alert only on conditions that need human action, use severities, route them to the right people and review noisy rules every month.
Problem
No diagnostic settings are configured, so detailed resource logs are never stored.
Why It’s Harmful
When an incident or a security question arises, there is no history to investigate, and the data cannot be recovered afterwards.
Correct Approach
Enable diagnostic settings through policy or templates on all important resources before they go live.
Problem
Every log from every machine is collected at full detail and kept at the most expensive plan and retention.
Why It’s Harmful
The monitoring bill rivals the cost of the systems being monitored, and finding useful signals gets harder.
Correct Approach
Collect what answers real questions, filter noise with data collection rules, choose table plans wisely and match retention to need.
Problem
Teams monitor only servers and databases, and nobody watches the user experience or the application itself.
Why It’s Harmful
Everything looks green while users suffer from slow pages or failing features that no infrastructure metric reveals.
Correct Approach
Add Application Insights, availability tests and user-facing measures such as error rate and response time at high percentiles.
Problem
Alert rules, dashboards and settings are created by hand in the portal and exist in nobody’s documentation.
Why It’s Harmful
Environments differ, rules are lost when someone leaves, and recreating monitoring after a disaster takes days.
Correct Approach
Define monitoring as code in version control and deploy it through the same pipelines as the application.
20Best Practices and a Starter Checklist
Walk through these steps whenever you set up monitoring for a new system.
Decide what matters
List what the business and users need from the system, and define simple health indicators for each.
Plan workspaces and access
Decide how many workspaces you need, who sees what and how long each type of data is kept.
Turn on the basics everywhere
Use policy to enable diagnostic settings, deploy the Azure Monitor Agent and attach data collection rules.
Instrument applications
Use Application Insights with OpenTelemetry, add availability tests and keep personal data out of telemetry.
Create actionable alerts
Alert on symptoms that users feel, route by severity and link each alert to a diagnosis guide.
Build useful views
Make a short health dashboard and workbooks for investigation, using insights as a starting point.
Control cost
Filter at the source, choose table plans, tune retention, consider commitment tiers and watch ingestion trends.
Automate and review
Define everything as code, test alerts regularly, and hold reviews after incidents to improve what you watch.
Alerting on everything, forgetting diagnostic settings, collecting all data forever, watching only infrastructure, leaving sensitive data in logs, giving everyone workspace-wide access, building monitoring by hand and never testing whether alerts really reach a human.
21Frequently Asked Questions
A metric is a number measured at regular intervals, light and fast, good for charts and quick alerts. A log is a detailed record of an event, heavier and slower, good for finding exactly what happened.
Platform metrics and the activity log are collected at no charge. You pay for things such as log ingestion and retention, alert rules, extra notifications and some advanced features. A small free allowance of log data is included.
It is the storage and query home for logs. Data sits in tables inside the workspace, and you search it with the Kusto Query Language. Several services, including Application Insights and Microsoft Sentinel, can use workspaces.
Detailed resource logs are not stored unless a diagnostic setting sends them to a destination. Create one and choose the categories you need. Logs only appear from the moment the setting is active.
No. The Azure Monitor Agent replaces the older agents, which have been retired. Use the new agent with data collection rules for new and migrated machines.
Application Insights is the application monitoring feature of Azure Monitor. It collects telemetry from your code, stores it in a Log Analytics workspace and offers views such as application map, failures and performance.
Alert only on conditions that need action, tune thresholds using real history, group related alerts, use severities and processing rules to mute planned maintenance, and review noisy rules regularly.
Platform metrics are kept for about three months. The activity log is kept for about ninety days. Workspace logs follow the retention you set, with a default period included and the option to keep data much longer at lower cost.
Yes. Diagnostic settings and data export can send data to storage accounts and Event Hubs, which many external tools can read. Some partner products also integrate directly.
Find the largest tables, filter low-value records and unused columns at the source, move noisy data to cheaper plans, shorten online retention where allowed, and consider a commitment tier at high volume.
22Summary and Key Takeaways
Azure Monitor is the central platform for knowing how your cloud systems behave. It gathers metrics, logs, traces and change records from applications, servers and Azure services, stores them in fast purpose-built stores, and lets you explore them with charts, workbooks and the Kusto Query Language. Alerts and action groups turn data into action, while data collection rules, careful retention and cheaper table plans keep cost under control. With monitoring defined as code, access carefully limited and alerts that people actually trust, you can notice problems early, fix them quickly and keep your promises to users.
Key Takeaways
- Four kinds of data — metrics for fast numbers, logs for detail, traces for request journeys and change records for what was altered.
- Some data is automatic, some needs setup — platform metrics and the activity log are collected for free, while resource logs need diagnostic settings and guest data needs the Azure Monitor Agent with data collection rules.
- Logs live in Log Analytics — use KQL to search them, and choose table plans and retention that match how often each kind of data is used.
- Application Insights watches your code — use it with OpenTelemetry for maps, traces, failures and availability tests, and keep personal data out of telemetry.
- Alerts must be actionable — combine rules with action groups, route by severity and fight alert fatigue by reviewing noisy rules.
- Control cost from the start — filter at the source, pick cheaper plans for noisy data, tune retention and watch ingestion trends.
- Treat monitoring as code — define rules and settings in templates, use policy for coverage, secure access and review the setup after every incident.