Azure Monitoring Tools: Advisor, Service Health and Azure Monitor

Azure Advisor is a free service that acts like a personal consultant for your Azure environment: it analyzes your resource configuration and usage, then gives you personalized recommendations to follow best practices and get more value from Azure. You see these recommendations in the Azure portal, each with its impact and the steps to act on it.

Advisor organizes its guidance into five categories, which map to the pillars of a well-run cloud workload: Cost (spend less, for example by resizing or shutting down underused resources), Security (reduce vulnerabilities and threats; these recommendations come from Microsoft Defender for Cloud), Reliability (improve the availability and resilience of your applications, for example by configuring backup or spreading virtual machines across availability zones), Operational excellence (improve process and deployment efficiency), and Performance (speed up and scale your applications).

Recommendations are suggestions, not automatic changes. You decide what to act on, and you can postpone a recommendation or dismiss one that does not apply to you.

Advisor versus Azure Monitor: data versus advice

Azure Monitor and Advisor work on the same resources but do different jobs. Azure Monitor collects the data: its metrics can show that a virtual machine has averaged a few percent CPU for weeks. It does not tell you what to do about it. Advisor is the service that interprets usage like that and turns it into an actionable recommendation, such as resizing or shutting down the underused VM. So when a need is "show me how this resource behaves", that is Azure Monitor; when it is "tell me what I should change to save money or improve reliability", that is Advisor. Advisor also does not tell you whether Azure is broken, and it is not a live monitoring dashboard.

Azure Service Health answers the question is a problem with Azure itself affecting my resources? Microsoft describes it as a family of three experiences, each with a wider or narrower scope:

Service Health covers three kinds of events: service issues (active outages in Azure that may be affecting you now), planned maintenance (upcoming work that could affect your resources, so you can prepare), and health advisories (changes that need your attention, such as a feature being retired or a configuration you should update). Because it is filtered to your subscriptions, it is more relevant than the public status page.

Resource Health zooms in further. It reports each resource as Available, Unavailable, Degraded or Unknown, keeps a history of past availability, and indicates whether an event was platform-initiated (an Azure-side problem) or user-initiated (for example, someone stopped or restarted the VM). It is built in and works for supported resources without any agent. Its value is the narrow scope: a platform problem confined to a single resource may never be large enough to appear as a service issue, yet Resource Health can still show that the platform affected that resource.

Service Health alerts notify you when a service issue, planned maintenance event or health advisory affects your subscription. They are delivered through the same action groups that Azure Monitor alerts use, so Service Health alerts can reuse any existing action group rather than needing a separate notification setup.

Azure Monitor is the comprehensive, full-stack monitoring platform in Azure: it collects, analyzes, and acts on telemetry from your applications, infrastructure and network. Telemetry is the data your resources emit about how they are behaving. While Advisor gives advice and Service Health reports on Azure's own status, Azure Monitor is where you watch your own workloads.

Azure Monitor is not limited to Azure resources. With the Azure Monitor Agent installed (machines outside Azure are typically connected through Azure Arc), it also collects data from on-premises servers and machines in other clouds into the same Log Analytics workspace as your Azure VMs. That lets one team investigate a hybrid environment with one set of queries, alerts and dashboards instead of a separate tool per location.

Because Azure Monitor is a platform, it is best understood through its main components, covered in the next sections: Log Analytics for querying log data, Azure Monitor alerts for being notified when something needs attention, and Application Insights for monitoring the performance and availability of your applications. Think of Azure Monitor as the umbrella, and these as the tools underneath it that do the specialized work. Azure Advisor and Azure Service Health are separate services, not parts of Azure Monitor.

The core of Azure Monitor's data platform is two data types: metrics and logs. Current Microsoft documentation also lists distributed traces and changes as data Azure Monitor works with, but metrics and logs are the two core types.

A few sources and settings come up often:

• Platform metrics are collected automatically for most Azure resources, so a VM's CPU chart is available with no setup.
• The activity log records control-plane operations on your subscription: who created, deleted, started, stopped or resized a resource, and when. It answers "what was done to this resource?", not "how is it performing?".
• Resource logs describe what happens inside a resource (for example, each request a storage account handles). They are not stored by default: you create a diagnostic setting on the resource to route them (and its metrics) to a destination such as a Log Analytics workspace, where you can then query them.

A diagnostic setting only sends data somewhere; it does not chart it, query it or alert on it. Those jobs belong to Metrics explorer, Log Analytics and alert rules.

Log Analytics is the tool within Azure Monitor for querying and analyzing log data. Logs collected by Azure Monitor are stored in a Log Analytics workspace, and Log Analytics is where you write queries against that data to answer questions and dig into what happened.

Queries are written in Kusto Query Language (KQL), a read-focused language designed for exploring large volumes of log data quickly. With KQL you can filter, sort, summarize, and chart your logs, for example, to count how many errors a service produced in the last hour, or to trace the sequence of events that led up to a failure. You do not need to master KQL for AZ-900; you need to know that Log Analytics is where you query logs, using KQL.

Log Analytics is powerful because it brings data from many sources, including on-premises and other-cloud machines, into one workspace, letting you correlate signals that would otherwise be scattered. Keep its near-twin apart: Metrics explorer charts metric values and needs no query language, while Log Analytics queries log records with KQL. If a need is about querying or analyzing collected log data, it belongs to Log Analytics, which is part of Azure Monitor.

Azure Monitor alerts notify you, or take an action automatically, when something in your environment meets a condition you care about, so you do not have to sit and watch dashboards. An alert has two separate parts:

• The alert rule defines what to watch and when to fire: the target resource, the signal (a metric, a log query, or an activity log event) and the condition, for example a virtual machine's CPU staying above 90 percent for five minutes.
• The action group defines what happens next: who is notified and how (email, SMS, push notification, voice call) and which automated actions run (a webhook, an Azure Function, a Logic App, an automation runbook).

Action groups are reusable. Many alert rules, on many resources, can point at the same action group, so the notification list is maintained once and shared, instead of being repeated inside every rule. Service Health alerts use action groups too, which is why one group can carry both your own alerts and Azure's maintenance and outage notices.

Metric alerts suit fast threshold checks because metrics are near real time; log alerts run a KQL query on a schedule and suit conditions that need more detail. Either way, the value is that you catch issues early, ideally before your users notice, and respond consistently every time. In short: Azure Monitor alerts notify you, or trigger an action, when a defined condition occurs.

Application Insights is the part of Azure Monitor focused on application performance monitoring (APM): understanding how your web applications and services behave from the inside. You enable it for your app, and it collects telemetry about how the application is running.

Application Insights tracks things like response times (how fast requests are served), failure and error rates (which requests are failing and why), request volumes and dependencies (how much traffic you get and how calls to databases or other services are performing), and usage (how people move through your app). It presents this as charts and detailed diagnostics, so you can pinpoint a slow page or a failing operation: which requests are slow and where the time is going.

Availability tests: checking your app from outside

Application Insights can also watch an app from the outside with availability tests. A standard availability test sends a request to your app's URL on a schedule (every few minutes) from several Azure locations around the world, records whether it succeeded and how long it took, and can raise an alert when it fails. Because the test calls the public URL, it needs no change to the application's code. Because the probes run on a schedule from several regions, they check reachability even during quiet periods, which telemetry from real users alone cannot do when there is little traffic.

The classic use case is the performance and availability of a live web app: to monitor a web application's performance, availability, and failures, use Application Insights, a feature of Azure Monitor. It is about your application, not Azure's own status.

The fastest way to place a need is to know which tool answers which question. Advisor is advisory, Service Health is about Azure's status affecting you, and Azure Monitor is about watching your own applications and infrastructure in detail. They are complementary, not competing.

Keep the scope in mind. Anything about spending, budgets, or the pricing calculator is cost management, and governance features such as Azure Policy and resource locks are separate topics. The tools you use to deploy and manage resources, the portal, CLI, PowerShell, Azure Arc, and templates, belong to another Domain 3 topic. This lesson is strictly about monitoring, so match the scenario to the tool whose core question fits.

Suppose you run an online store on Azure, and three different things happen in one week. Each one points to a different monitoring tool.

First, customers complain that the product page loads slowly. You open Application Insights and look at response times and failures for your web app. It shows that one type of request, a call to your database, is taking far longer than the rest, so you know exactly where to focus. That is application performance monitoring in action.

Second, you notice sporadic errors and want to confirm a pattern. You use Log Analytics to run a KQL query over your collected logs, counting errors by hour, and you set an Azure Monitor alert so you are emailed if the error rate spikes again. Now you will be told the moment it recurs.

Third, several unrelated services in one region briefly misbehave. You check Azure Service Health, which shows an active service issue in that region affecting your resources, reassuring you it is Azure's problem, not yours. Later, Azure Advisor recommends resizing an underused virtual machine to cut costs. Three signals, three tools, each doing its own job.