Azure Monitor is Microsoft’s service for collecting, analyzing and acting on information about your applications and the resources they run on.

The problem it solves

When software ran on a single server in a back room, monitoring meant glancing at that one machine. Modern systems are different. A single customer request may touch a web front end, several internal services, a database, a cache and a message queue, each running on different infrastructure. If the request is slow, which part is to blame? Without a central view, teams jump between tools, compare timestamps by hand and guess.

Azure Monitor gathers information from all of those parts into one platform. It lets you ask questions across everything at once, draws charts of health, and sends a message to the right person when something goes wrong. It also supports automatic reactions, such as adding more servers when demand rises.

What it covers

Azure Monitor works with Azure resources such as virtual machines, databases and web apps. It also reaches beyond Azure, collecting data from servers in other clouds and on-premises data centers, from containers and Kubernetes clusters, and from custom applications that send their own data. This makes it practical for companies that run a mix of environments.

Monitoring versus observability

You will often hear two related words. Monitoring means watching for known problems, such as a server running out of disk space. Observability means having enough detailed data that you can investigate problems you did not predict. Azure Monitor supports both: dashboards and alerts for the known, and rich search over logs and traces for the unknown.

Everything Azure Monitor collects falls into a few categories, and knowing the difference tells you which one to reach for.

Why you need more than one

Each type answers a different question. A metric tells you that something is wrong, such as response time doubling. A trace shows where the delay happens, perhaps in a call to a database. A log explains why, perhaps a specific error message. A change record reveals what likely triggered it, such as a deployment ten minutes earlier. Used together they turn a vague complaint into a clear diagnosis.

Azure Monitor follows a simple flow: data comes in from sources, lands in a data platform, and is used by tools that show, alert and automate.

flowchart LR
    SRC["Sources: applications, VMs, containers, Azure resources, custom data"] --> COL["Collection: agents, diagnostic settings, SDKs, APIs"]
    COL --> MET["Metrics store"]
    COL --> LOG["Logs store: Log Analytics workspace"]
    COL --> TRC["Traces and application data"]
    MET --> USE["Use: charts, workbooks, dashboards"]
    LOG --> USE
    TRC --> USE
    MET --> ACT["Respond: alerts, autoscale, automation"]
    LOG --> ACT
        

Three layers to remember

Why the layers matter

Separating these layers explains many design decisions. You can change where data is collected from without touching your dashboards. You can add a new alert without collecting any new data. And you can send the same data to several places at once, such as keeping a copy in cheap storage for compliance while also analyzing it in a workspace for daily operations.

Azure Monitor collects from several layers of your environment, from the application down to the subscription itself.

flowchart TD
    A["Application code"] --> AM["Azure Monitor"]
    B["Guest operating system"] --> AM
    C["Azure resources"] --> AM
    D["Azure subscription"] --> AM
    E["Azure tenant"] --> AM
    F["Custom and external sources"] --> AM
        

Platform data comes free, resource detail is opt-in

Two kinds of information appear without effort. Platform metrics show basic health for every Azure resource, and the activity log records who did what at the subscription level. Resource logs, which hold the detailed events inside a service, are not collected unless you create a setting to send them somewhere. Many newcomers wonder why a chart is empty, and the answer is often that this setting has not been created.

Metrics are the quick pulse of your system, and they are the foundation of most alerts and charts.

What a metric is

A metric is a number recorded at regular intervals, together with a timestamp. Examples include the percentage of processor in use, the number of requests handled per minute, or the amount of free disk space. Because metrics are small and structured, they are stored in a database built for time-series data, which makes queries very fast and lets charts update almost in real time.

Dimensions

Many metrics carry dimensions, which are extra labels that let you slice the data. A request count might have a dimension for the response status, so you can see successes and failures separately, or a dimension for the server instance, so you can spot one unhealthy machine among many. Dimensions turn one metric into many views without storing separate metrics.

Aggregation

Raw metric values are combined over time periods using aggregations such as average, minimum, maximum, sum and count. Choosing the right one matters. An average processor use of forty percent might hide short spikes to one hundred percent, while the maximum would reveal them. For counts, the sum over a period is usually what you want.

Metrics Explorer

Metrics Explorer is the tool for charting metrics. You choose a resource, pick a metric, select an aggregation, add filters or splits by dimension, and the chart appears. You can place several metrics on the same chart, compare resources side by side, and pin the result to a dashboard. For many everyday questions, this is the fastest route to an answer.

Retention and Prometheus metrics

Platform metrics are kept for a limited period, roughly three months, which is enough for most operational use. For longer history, you can send metrics to a Log Analytics workspace or a storage account. Teams that run containers often use Prometheus, a popular open-source metrics format. Azure Monitor offers a managed service for Prometheus metrics, so you can keep that familiar approach without running the storage yourself.

Logs hold the rich, detailed story of what happened, and the Log Analytics workspace is the home where most of them live.

What a workspace is

A Log Analytics workspace is a container for log data, with its own settings for retention, access and cost. Inside, data is arranged in tables, each with a defined set of columns. There are tables for virtual machine performance, for web requests, for security events, for resource activity and many more. All the tables in a workspace can be searched together, which allows questions that cross many sources.

Table plans

Not all log data deserves the same treatment. Azure Monitor lets you choose a plan per table, balancing cost against capability.

Retention and archive

Each table keeps data for a chosen number of days. After that period, data can be deleted or moved to a low-cost archive state, where it stays available for longer-term needs and can be restored or searched on demand. Setting retention per table, instead of one value for the whole workspace, avoids paying premium prices to keep unimportant data for years.

Many sources, one place

Because so many kinds of data land in the same workspace, you can ask joined-up questions. For example, you can match an increase in web errors with a spike in database timeouts and a deployment that happened shortly before. That cross-checking is the heart of effective troubleshooting, and it is hard to do when each tool keeps its own separate store.

Kusto Query Language, usually shortened to KQL, is how you ask a workspace questions, and its logic is easier than it looks.

The pipe idea

A KQL question reads like a sentence with steps. You begin by naming a table, then pass the rows through a series of steps joined by a pipe symbol. Each step takes the result of the previous one and refines it. You might filter to a time range, keep only error rows, count them by server, sort the result and show the top five. Because the steps read in order, even a long question stays understandable.

Common kinds of steps

Where queries are used

Queries are not only for exploration. The same question you write while investigating can be saved, pinned to a workbook or dashboard, or turned into an alert rule that runs on a schedule. This reuse is powerful: a manual investigation that you repeat often becomes automatic monitoring.

Writing efficient queries

Queries scan data, so narrower questions are faster and cheaper. Always limit the time range first, since the time filter is the most efficient way to skip data. Filter early, before heavy steps such as joins, and keep only the columns you need. A habit of starting narrow and widening only if necessary keeps both the query time and the load on the workspace low.

Diagnostic settings decide where the detailed output of an Azure resource goes, and the activity log records who did what to your subscription.

Diagnostic settings

A diagnostic setting is a small configuration attached to a resource. It says which categories of logs and metrics to export, and where to send them. One setting can send data to several destinations at once, which is useful when different teams need the same data for different reasons.

Enforcing settings with policy

In a large organization, people forget to create diagnostic settings, and the missing logs are noticed too late. Azure Policy can solve this by automatically deploying a setting to every new resource of a given type, or by flagging resources that lack one. This turns logging from an individual habit into an organizational guarantee.

The activity log

The activity log is a record of management actions at the subscription level. It answers questions like who deleted this virtual machine, when was this setting changed and which deployment failed. It is collected automatically and kept for a limited period, so for longer retention or alerting you send it to a workspace. It is one of the most useful sources for connecting a problem to a human or automated change.

To see inside a machine, you need a small program running on it, and a rule that says what it should collect.

The agent

Azure Monitor Agent is software installed on virtual machines and servers, in Azure or elsewhere. It collects performance counters, system logs and other data from inside the operating system and sends it to Azure Monitor. It replaces older agents that had overlapping jobs, so new work should use it. Machines outside Azure can be connected through Azure Arc, which brings them under the same management.

Data collection rules

A data collection rule, usually shortened to DCR, defines what to collect, optionally how to transform it, and where to send it. The agent is simply the carrier, and the rule is the instruction sheet. Many machines can share one rule, so a single change updates the behavior of hundreds of machines. A machine can also follow several rules at once.

flowchart LR
    VM1["Virtual machine 1 with agent"] --> DCR["Data collection rule"]
    VM2["Virtual machine 2 with agent"] --> DCR
    VM3["On-premises server with agent via Arc"] --> DCR
    DCR --> TF["Optional transformation: filter and shape"]
    TF --> WS["Log Analytics workspace"]
    TF --> MT["Metrics store"]
        

Transformations save money

One of the most valuable features of a data collection rule is the ability to transform data before it is stored. You can drop rows you will never use, remove columns that are too large, or split data into different tables. Because cost depends on how much data is ingested, filtering unneeded data at this point reduces the bill directly, without losing the information that matters.

Data collection endpoints and custom data

For custom sources, such as an application that sends its own business events or a device that is not a standard server, Azure Monitor offers a public interface for ingesting logs. Data sent this way still follows a data collection rule, so you keep the same control over structure, filtering and destination. Where a network must be private, data collection endpoints give a defined, controlled entry point.

Application Insights watches your application code itself, telling you how real users experience it.

What it is

Application Insights is the application performance monitoring part of Azure Monitor. It collects information about requests coming into your application, calls your application makes to other services, errors and exceptions, page loads in the browser, and custom events that you define. It works with many languages and frameworks, and it stores its data in a Log Analytics workspace so it can be searched together with infrastructure data.

Key features

Distributed tracing

In a system built from many services, one user action spawns many internal calls. Distributed tracing links all of them together using a shared identifier that travels with the request. In the trace view, you see the request as a timeline, with each service call shown as a bar. The longest bar shows where the time went, so you stop guessing and look straight at the slow part.

sequenceDiagram
    participant U as User
    participant W as Web front end
    participant O as Orders service
    participant P as Payments service
    participant D as Database
    U->>W: Place order
    W->>O: Create order
    O->>D: Save order
    D-->>O: Saved
    O->>P: Charge card
    P-->>O: Approved
    O-->>W: Order confirmed
    W-->>U: Success page
        

OpenTelemetry and sampling

Microsoft recommends instrumenting applications with OpenTelemetry, an open standard for producing traces, metrics and logs. Using a standard avoids lock-in and lets you send the same data to several tools. Because large applications produce enormous volumes of telemetry, sampling is often used. Sampling keeps a representative fraction of the data, often keeping all failures while thinning out routine successes, which controls cost while preserving the useful signals.

For popular resource types, Azure Monitor provides curated experiences that save you from building everything yourself.

What insights are

An insight is a packaged monitoring experience for a particular kind of resource. It bundles the data collection, the dashboards and often the recommended alerts, all tuned for that resource type. Instead of deciding from scratch which counters matter for a virtual machine, you enable the insight and receive a sensible default view.

Managed Prometheus and Managed Grafana

Teams that already use Prometheus for metrics and Grafana for dashboards can keep their familiar tools. Azure Monitor managed service for Prometheus stores and queries Prometheus metrics at scale, and Azure Managed Grafana provides hosted Grafana dashboards integrated with Azure sign-in and data sources. You get the popular open-source experience without running the servers behind it.

Data is only useful when the right people can see it in a form they understand.

Workbooks

Workbooks are the most flexible built-in reporting tool. A workbook mixes written explanation, parameters such as a time range or a chosen resource, and charts or tables driven by metrics and log queries. Because they are interactive, a workbook can guide a person through an investigation: pick a service at the top and every section below updates. They can be shared with a team and reused across environments.

Designing a dashboard that works

A good dashboard answers a few clear questions. Is the service healthy right now? Are users affected? Is something trending badly? Place the most important signals at the top and keep the page uncluttered. A wall of forty small charts looks impressive but helps nobody. A useful rule is that someone who has never seen the dashboard should be able to tell in ten seconds whether things are fine.

Alerts turn data into action by notifying people, or triggering automation, when conditions are met.

Anatomy of an alert

An alert rule has four main parts. It has a scope, which says which resources it watches. It has a condition, which says what counts as a problem. It has a severity, which says how serious the problem is. And it has actions, which say who is told or what happens automatically. When the condition is met, the rule creates an alert, which can be tracked and closed like a ticket.

Types of alert rules

Static and dynamic thresholds

A static threshold is a fixed number, such as alert when processor use stays above ninety percent. A dynamic threshold learns the normal pattern of a metric, including daily and weekly rhythms, and alerts when the value departs significantly from it. Dynamic thresholds suit metrics whose normal level changes through the day, such as website traffic, where any fixed number would either miss problems at night or fire constantly at noon.

Severity levels

Alerts carry a severity from zero, the most serious, to four, the least. A consistent meaning for each level, agreed across the organization, is essential. Critical levels should wake someone up, while informational ones should be reviewed during working hours. If everything is marked critical, then nothing is, and people learn to ignore the pager.

Stateful alerts

Alerts have a lifecycle. For most metric alerts, the alert is fired when the condition becomes true and is resolved automatically when it returns to normal, so you are not flooded with repeated notices for one ongoing problem. Understanding this behavior helps you design rules that signal the start and end of an incident cleanly.

An alert that reaches the wrong person, or too many people, is almost as bad as no alert at all.

Action groups

An action group is a reusable list of things that happen when an alert fires. Many alert rules can share one action group, and changing the group updates them all. The actions can notify people and also start automated responses.

Alert processing rules

Alert processing rules sit between the alert and its action group, and let you change what happens without editing every alert rule. You can suppress notifications during planned maintenance, add an action group to every alert from a certain subscription, or limit certain alerts to working hours. This is the clean way to handle planned downtime without disabling alerts and risking that you forget to turn them back on.

flowchart LR
    DATA["Metric or log data"] --> RULE["Alert rule evaluates condition"]
    RULE --> ALERT["Alert fired with severity"]
    ALERT --> APR["Alert processing rule: suppress, add or route"]
    APR --> AG["Action group"]
    AG --> N1["Notify on-call person"]
    AG --> N2["Create incident ticket"]
    AG --> N3["Run automated runbook"]
        

Fighting alert fatigue

Alert fatigue happens when people receive so many notices that they stop reading them. It is dangerous because real emergencies hide among the noise. The remedies are simple. Alert only on conditions that need human action. Remove alerts nobody acts on. Use dynamic thresholds for variable metrics. Group related alerts. Review alert history regularly and ask of each one: did this lead to action?

Autoscale uses monitoring data to add or remove capacity automatically, matching resources to demand.

The idea

Demand for most applications changes through the day and the week. Running enough servers for the busiest hour all the time wastes money, while running too few causes slowness at peak. Autoscale watches metrics, such as processor use or queue length, and adds instances when demand rises and removes them when it falls. It is supported by many Azure services, including virtual machine scale sets and web hosting plans.

Scale rules

Schedules and predictive scaling

Rules react to what has already happened. When demand is predictable, such as a sale starting at nine in the morning, a scheduled profile can add capacity beforehand. For some services, predictive autoscale studies past patterns and prepares capacity ahead of expected load. Combining scheduled and reactive rules gives both readiness and flexibility.

How you arrange workspaces and permissions shapes cost, convenience and security for years.

How many workspaces?

There is no single right answer, but there is a useful default. Fewer workspaces make it easier to search across everything and simplify management. More workspaces give clearer separation of cost, access and data location. Most organizations land somewhere between a single central workspace and one workspace per team.

Reasons to separate

Common reasons to create separate workspaces include regulations requiring data to stay in a particular region, strict separation between production and non-production, different retention needs, or a business unit that insists on managing its own costs and access. Without such a reason, extra workspaces mostly add overhead.

Access control

Azure Monitor uses role-based access control. Built-in roles such as Monitoring Reader give read-only access to monitoring data, Monitoring Contributor allows changes to monitoring settings, and Log Analytics Reader and Contributor control workspace access. Workspaces support two access styles. In workspace-context, a person sees all data in the workspace they are allowed into. In resource-context, a person sees only the logs for the resources they already have rights to, which lets application teams query their own data in a shared workspace without seeing everyone else’s.

Monitoring data often contains sensitive information, so it deserves the same protection as the systems it describes.

What could go wrong

Logs can accidentally contain personal details, passwords, tokens or internal addresses, especially when applications print too much information. A workspace that is broadly readable could expose all of it. Equally, monitoring is a security tool in its own right, because the logs show suspicious sign-ins, strange changes and attacks in progress.

Private connectivity

Organizations with strict network rules can create an Azure Monitor Private Link Scope. This lets virtual networks reach Azure Monitor over private addresses and, if desired, blocks access over the public internet. Data collection endpoints give agents a defined private entry point. Plan these early, because changing network arrangements later is harder.

Monitoring as a security tool

Security teams rely on logs to detect threats. Azure Monitor data, such as sign-in records and resource activity, can feed security analysis tools, and diagnostic settings can stream it to them. Good monitoring therefore serves two audiences with one set of data: operations teams looking for reliability problems and security teams hunting for attacks.

Monitoring is essential, but a careless setup can quietly become one of the largest items on a cloud bill.

What drives cost

Most of the cost of Azure Monitor comes from the volume of log data ingested into workspaces, followed by how long it is retained, and then by charges for alert rules and certain features. Metrics from Azure resources are generally cheap or free, while detailed logs are where money is spent. Application telemetry can also grow very large in busy systems.

Practical ways to save

Daily caps

A workspace can have a daily data cap that stops ingestion once reached. This protects against surprise bills, but it has a dark side: when the cap is hit, new data is lost, which can leave you blind during exactly the kind of event that creates log floods. Most teams prefer alerts on unusual ingestion volume over a hard cap on important workspaces.

Tools are only half the story; the other half is deciding what really matters and how to react.

Start from the user

Good monitoring begins with the question of what the user experiences. Define a few service level indicators, which are measurable aspects of user experience such as the share of requests that succeed or the time to respond. Then agree on service level objectives, which are targets for those indicators, such as ninety-nine point nine percent of requests succeeding over a month. These targets drive what you alert on and how much risk you accept.

The golden signals

A widely used checklist for any service is the four golden signals.

Layers of monitoring

Effective monitoring watches several layers at once and connects them. At the top is the user experience, measured by synthetic tests and real-user data. Below that is the application, with requests, dependencies and errors. Below that is the infrastructure, with machines, containers and networks. Below that is the platform and subscription, with service health and changes. When an alert fires at the top, you drill down through the layers to find the cause.

flowchart TD
    L1["Layer 1: User experience and availability tests"] --> L2["Layer 2: Application requests, dependencies, errors"]
    L2 --> L3["Layer 3: Infrastructure: VMs, containers, network"]
    L3 --> L4["Layer 4: Platform: service health, activity log, changes"]
        

Plan for incidents, not just alerts

An alert is only the start. Decide who is on call, how they escalate, where they discuss the incident and where they find a guide for common problems. After each serious incident, hold a blameless review to learn what monitoring would have shown the problem sooner, and improve it. A monitoring system that learns from every incident becomes steadily more useful.

Monitoring becomes far more powerful when it is connected to how you build, release and respond.

Monitoring in the release process

Delivery pipelines can use monitoring data as a safety net. A deployment can be marked in your telemetry as an annotation, so every chart shows exactly when a release happened. An environment check in Azure Pipelines can query Azure Monitor alerts and refuse to proceed if there are active alerts, so a new release does not pile onto an existing problem. During a gradual rollout, health measures decide whether to widen it or roll back.

Connecting to work and communication tools

Action groups can create work items, open tickets and post to team chat. This ensures that a problem becomes a tracked piece of work with an owner, rather than a message that scrolls away. Linking alerts to the runbooks or documents that explain the response shortens the time to recovery, especially for people who are new on call.

Service health and resource health

Not every problem is yours. Azure Service Health tells you when Microsoft has an incident, planned maintenance or advisory affecting your services, and Resource Health tells you whether a specific resource is healthy from the platform’s point of view. Alerts on these save time, because they quickly separate a problem in your application from a problem in the underlying service.

Teams that monitor well repeat certain habits and avoid certain traps.

Patterns worth adopting

Traps to avoid

A short checklist, followed by examples of the ideas working together.

Real-world scenarios

flowchart TD
    S["Symptom: customers report slow payments"] --> A1["Check alert and dashboard: response time high"]
    A1 --> A2["Open application map: payments service unhealthy"]
    A2 --> A3["Open trace: slow call to database"]
    A3 --> A4["Query logs: timeouts began at 10:05"]
    A4 --> A5["Check activity log: setting changed at 10:00"]
    A5 --> FIX["Revert change and confirm recovery"]
        

No. It can also collect from servers in other clouds and on-premises through agents connected with Azure Arc, and it accepts custom data through public interfaces, so one platform can watch a mixed environment.

Metrics are lightweight numbers recorded over time, ideal for quick health checks and alerts. Logs are detailed event records, ideal for investigating why something happened. Most real investigations use both.

Detailed resource logs are not stored unless you create a diagnostic setting that sends them to a destination such as a workspace. Platform metrics and the activity log appear automatically, but resource logs need that setting.

Usually yes. Machine monitoring shows whether the infrastructure is healthy, while Application Insights shows how the application behaves for real users, including slow requests, failing dependencies and exceptions.

It is a configuration that defines which data an agent or interface collects, how it may be filtered or reshaped, and where it is sent. Many machines can share one rule, which makes changes easy to roll out.

Use dynamic thresholds for metrics whose normal level changes with time, such as web traffic that varies by hour. Use static thresholds for hard limits that should never be crossed, such as a disk being almost full.

Find the tables and resources that ingest the most data, filter unneeded rows with data collection rules, move rarely used tables to cheaper plans, shorten interactive retention, use commitment tiers for steady high volumes and sample application telemetry.

Start with as few as your requirements allow. Separate only for data-location rules, strong isolation needs, different retention policies or independent cost responsibility. Resource-context access often removes the need for separate workspaces.

Use an alert processing rule that suppresses notifications for the maintenance window. This is safer than disabling alert rules, because the rules automatically resume without anyone having to remember to switch them back on.

Yes. Managed Grafana connects directly to Azure Monitor data, and action groups can call webhooks and connect to service management tools, while streaming through Event Hubs reaches many external platforms.

It can be, if you apply least-privilege access, private networking, encryption and careful data scrubbing. The best protection is to avoid logging sensitive values in the first place.

Azure Monitor gathers metrics, logs, traces and change records from applications, machines, containers and Azure services into one platform. Agents and data collection rules bring data in, diagnostic settings export what resources produce, and Application Insights shows how real users experience your software. Workspaces, workbooks and dashboards make the data understandable, while alerts, action groups and autoscale turn it into action. The best results come from good design rather than more data: start from user experience, alert on symptoms, protect sensitive information, control cost with filtering and tiered plans, and keep improving after every incident.