Azure Monitor: product and architecture
If your workloads already sit behind Azure Resource Manager, this Azure Monitor review reaches a straightforward verdict: it is the default observability service for that estate, and you should need a specific reason to run something else alongside it. Azure Monitor is not a generic "monitoring category" product — it is Microsoft's first-party telemetry pipeline, log store, and alerting engine for Azure, hybrid, and multicloud resources, sold on data volume rather than per host or per seat. That billing model is the single most important thing to understand before adopting it, because it makes your monitoring bill a direct function of how noisy your applications and agents are.
Overview
Azure Monitor collects metrics, logs, and traces from applications, infrastructure, and network resources, then exposes them through curated dashboards, a centralized log platform, and an alerting and autoscale layer. Microsoft positions it as end-to-end observability with "fast onboarding and a high-quality standard backed by Azure SLAs" for Azure, multicloud, and hybrid resources — the SLA backing being the practical differentiator versus rolling your own Prometheus-and-Grafana stack on the same subscriptions.
The product has been moving in the direction of assisted triage. The Azure Copilot Observability Agent reached general availability, which places an LLM-driven investigation layer on top of the same telemetry store rather than in a separate tool. We have no independent accuracy or time-to-resolution data for that agent, so we would treat it as a convenience for first-pass triage and not as a reason to select the platform.
The application instrumentation side is genuinely open. The Application Insights .
NET SDK (ApplicationInsights-dotnet) is MIT-licensed, written primarily in C#, and carries repository topics covering application-insights, distributed-tracing, logging, monitoring, observability, sdk, and telemetry. It has 610 GitHub stars — a public interest signal for the SDK specifically, not a measure of how many enterprises run Azure Monitor, which is overwhelmingly adopted through the portal rather than through the repo. Maintenance is active: the latest tagged release is v3.1.2 (28 May 2026), with commits pushed as recently as 20 August 2026.
Key Features and Architecture
Azure Monitor is best understood as a two-store architecture — a time-series metrics store optimized for cheap, high-frequency numeric data, and a log store used for anything with structure or free text — sitting under a shared query, visualization, and alerting surface.
- Centralized logs platform with tiered tables. Log data lands in Log Analytics workspaces, queried with KQL. The tiering matters architecturally: Auxiliary Logs tables exist as a lower-cost destination for high-volume, low-query-frequency data such as verbose network or firewall logs, billed separately at $0.10 per GB for ingestion. Designing which table class each stream goes to is the main cost lever you control.
- Curated insights. Rather than making you build dashboards from raw counters, Azure Monitor ships pre-built monitoring experiences scoped to a particular service or set of services with minimal configuration — VM monitoring and Kubernetes cluster monitoring being the two most heavily used. This is the fastest path from "agent installed" to "usable signal," and it is where the product earns its onboarding claim.
- Distributed tracing via Application Insights. The SDK instruments request, dependency, and exception telemetry and stitches calls across service boundaries. Because the .
NET SDK is MIT-licensed and public, you can read exactly what the sampling and telemetry-processor pipeline does before you ship it — useful when you need to justify instrumentation overhead or data residency behavior to a platform review board.
- Visualization across a distributed estate. The visualization layer is designed to render ingested data from distributed environments on a single pane of glass, spanning Azure-native resources, on-premises machines, and other clouds in the same view. That cross-boundary view is the reason hybrid shops keep it even when individual teams prefer other tooling.
- Critical situation response. Alert rules fire near-real-time notifications and can trigger autoscale actions when load increases, closing the loop between detection and remediation without an external automation tool. Alerts, notifications, web tests, and data export are billed as separate line items rather than bundled into ingestion.
- Open extensibility. Microsoft describes the platform as open-source-based with integrations into Azure services and third-party tools, so custom solutions can be built on the same telemetry rather than duplicating collection.
Ideal Use Cases
Azure-first platform teams running mixed VM and Kubernetes estates. A platform group of five to eight engineers supporting a few hundred virtual machines and several AKS clusters gets the most value here. Curated insights for VMs and containers cover the majority of infrastructure questions without dashboard engineering, and the autoscale integration means capacity response is configured in the same place as detection. This is the profile where we recommend Azure Monitor without reservation.
.
NET application teams that need distributed tracing. If your services are C#/.
NET, the Application Insights SDK is the shortest path to request-level tracing and exception telemetry, and its MIT license and v3.1.2 release cadence make it a dependency you can reason about. Teams running polyglot stacks should validate SDK maturity per language before committing — our data covers the .
NET SDK specifically.
Hybrid and regulated environments. Organizations in financial services, healthcare, or the public sector that keep workloads on-premises while expanding into Azure benefit from Azure SLAs on a monitoring plane that spans both. Consolidating hybrid telemetry into one log platform is materially easier to defend in an audit than correlating three separate tools.
Don't use this if your estate is predominantly AWS or GCP with Azure as a minority footprint. You will pay ingestion egress-style costs to pull foreign-cloud telemetry into a Log Analytics workspace while your primary cloud's native monitoring already collects it for free or near-free. Equally, avoid it if you need a fixed, predictable monthly monitoring line item and cannot staff someone to own ingestion governance — usage-based billing punishes teams that ship debug-level logging to production and forget about it.
Strengths & Trade-offs
Pros
- Zero-integration coverage of Azure resources. Platform metrics for Azure resources are available without deploying agents or writing collectors, so a new subscription is observable the day it is created. This removes an entire class of instrumentation-gap incidents.
- Curated insights collapse time-to-value. Service-specific monitoring experiences for VMs and Kubernetes clusters arrive configured, so a team gets useful dashboards with minimal configuration instead of a dashboard-building project.
- Auditable, MIT-licensed instrumentation. The Application Insights .
NET SDK is public, actively maintained (v3.1.2, released 28 May 2026; pushes through 20 August 2026), and carries no license cost — you can fork or patch telemetry processors rather than filing a support ticket.
- Detection and remediation live in one place. Near-real-time alerts can drive autoscale directly, so load-driven capacity response does not require a separate automation platform or a webhook chain to maintain.
- Contractual reliability. Coverage is backed by Azure SLAs across Azure, hybrid, and multicloud resources, which matters when monitoring itself is in scope for an availability commitment.
Cons
- Cost scales with verbosity, not value. Because billing is ingestion-volume-based, one team enabling debug logging on a chatty service can move the monthly bill without anyone approving a change. Controlling this requires ongoing table-tier and sampling governance that nobody naturally owns.
- Charges are fragmented across meters. Alerts, notifications, web tests, and data export are billed on top of ingestion, so the "what will this cost" question has no single answer and forecasting requires modeling several meters at once.
- KQL is a real learning curve. Deep troubleshooting on the log platform means writing Kusto queries. Analytics engineers fluent in SQL pick it up, but it is a distinct language and a distinct skill to hire for, and shallow KQL skills push teams back onto the curated dashboards where the hard questions cannot be answered.
- Reservation commitments create lock-in pressure. Capturing the up-to-36-percent discount means committing ingestion volume in advance, which raises the switching cost mid-term and biases teams toward keeping data in Azure Monitor even when another tool would serve a given workload better.
- Gravity toward the Microsoft stack. The richest experience — curated insights, portal integration, .
NET tracing — is on Azure and .
NET. Non-Azure and non-.
NET coverage exists, but you should verify parity for your specific runtimes rather than assume it.
