Azure monitoring for VMs, AKS, App Service and Azure SQL
Pull Azure Monitor metrics from every subscription without agents, add host and Kubernetes depth with the Obseria Agent, and trace requests end to end with OpenTelemetry.
Why monitor Azure with Obseria
One view across subscriptions
Connect subscriptions with a read-only service principal and see VMs, AKS, App Service, Functions and databases side by side.
From platform metric to code
Correlate Azure Monitor metrics with OpenTelemetry traces and logs, so an Http5xx spike leads straight to the failing dependency.
Kubernetes depth on AKS
Run the Obseria Agent as a DaemonSet for node, pod and container data that platform metrics alone do not show.
Azure services Obseria monitors
- Azure Virtual Machines and scale sets. CPU, available memory, disk and network per VM, plus processes and logs with the Obseria Agent.
- Azure Kubernetes Service (AKS). Node and pod health from AKS platform metrics, enriched with container data from the Obseria Agent.
- Azure App Service. Requests, response time, HTTP 4xx/5xx and instance health for web apps and APIs.
- Azure Functions. Executions, failures and execution units per function app, with traces for each invocation.
- Azure SQL Database. CPU, DTU or vCore consumption, storage, connections and deadlocks per database.
- Azure Monitor and Activity Log. Platform metrics from any resource type, plus resource changes and service health events.
The Azure signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.Virtual machine health
Shows whether your virtual machines have enough processing power and memory to keep business applications running smoothly.
Container platform stability
Tells you whether your container platform has spare capacity and whether all application parts are up and ready.
Web app experience
Reveals how fast your web apps respond, how often users see errors and how busy your background functions are.
Database load
Shows whether your databases are under strain or blocking each other, which can slow down orders and reports.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
Microsoft.Compute/virtualMachines Percentage CPU | Percent | CPU in use on the VM; the first indicator for scaling or rightsizing. |
Microsoft.Compute/virtualMachines Available Memory Bytes | Bytes | Memory immediately available to processes on the VM. |
Microsoft.ContainerService/managedClusters node_cpu_usage_percentage | Percent | Aggregated CPU usage per AKS node. |
Microsoft.ContainerService/managedClusters kube_pod_status_ready | Count | Number of pods in Ready state; drops reveal failing workloads. |
Microsoft.Web/sites Http5xx | Count | Server errors returned by an App Service app. |
Microsoft.Web/sites HttpResponseTime | Seconds | Time the app takes to serve requests. |
Microsoft.Web/sites FunctionExecutionCount | Count | Function executions per function app, the base for throughput and failure rates. |
Microsoft.Sql/servers/databases cpu_percent | Percent | CPU consumption of the database relative to its limit. |
Microsoft.Sql/servers/databases deadlock | Count | Deadlocks detected in the database. |
Set up Azure monitoring in minutes
- Step 1
Create a read-only service principal
Register a service principal in Microsoft Entra ID and assign the Monitoring Reader role, plus Reader for resource and tag discovery, at subscription or management group scope.
- Step 2
Connect subscriptions in Obseria
Enter tenant ID, client ID and secret, select subscriptions and resource types, and Azure Monitor metrics start flowing agentlessly.
- Step 3
Add agent and OpenTelemetry
Install the Obseria Agent on VMs or via Helm on AKS, and configure OpenTelemetry SDKs with your OTLP endpoint for traces.
# Read-only service principal for Obseria at subscription scope
az ad sp create-for-rbac \
--name obseria-reader \
--role "Monitoring Reader" \
--scopes "/subscriptions/${SUBSCRIPTION_ID}"
# Allow resource and tag discovery (use the appId from the output above)
az role assignment create \
--assignee "${OBSERIA_APP_ID}" \
--role "Reader" \
--scope "/subscriptions/${SUBSCRIPTION_ID}"Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- Azure subscription overview by resource group
- VM and scale set health with rightsizing hints
- AKS cluster, node and pod health
- App Service and Functions error rate alerts
- Azure SQL performance and deadlock alerts
Azure monitoring: what matters
Why Azure monitoring needs a unified view
Azure monitoring usually starts with Azure Monitor, which collects platform metrics for nearly every resource type. It is the authoritative source for what the Azure fabric sees, but a production workload rarely lives in one resource. A typical application spans App Service or AKS, a few Function apps, Azure SQL, a storage account and a Service Bus namespace, often across several subscriptions owned by different teams.
When something breaks, engineers need to know which of these parts failed first and why. Azure observability means bringing platform metrics, application traces, logs and change events into one place, linked by resource IDs and tags, so the path from symptom to cause is short and does not depend on knowing which blade to open.
The Azure metrics that matter
Focus on the golden signals per tier and use resource metrics to explain them:
- Virtual machines:
Percentage CPU,Available Memory Bytes, disk operations and network throughput. Guest-level detail such as per-process CPU comes from the Obseria Agent. - AKS:
node_cpu_usage_percentage, node memory working set,kube_pod_status_readyand node conditions, plus container restarts and OOM kills from the agent. - App Service:
Requests,HttpResponseTime,Http5xxandHttp4xx, and instance-level CPU and memory of the App Service plan. - Azure Functions:
FunctionExecutionCountand execution units on Consumption plans, plus failures and duration from traces. - Azure SQL Database:
cpu_percent,dtu_consumption_percentor vCore usage,storage_percent,connection_failedanddeadlock.
Common Azure problems and how to detect them
Plan saturation on App Service. Several apps share one App Service plan. If one app consumes the plan's CPU, response times rise for all of them. Comparing HttpResponseTime per app with plan CPU shows who is the noisy neighbor.
Database throttling. When Azure SQL reaches its DTU or vCore limit, queries queue and latency climbs. Sustained cpu_percent or dtu_consumption_percent near 100 percent, together with slow database spans in traces, confirms throttling rather than an application bug.
Cold starts and timeouts in Functions. Consumption-plan functions that scale from zero can add latency to the first requests. Traces show the cold start as part of each invocation, so you can decide whether a premium plan or pre-warmed instances are worth it.
AKS node pressure. Pods that are evicted or never become ready often point to memory pressure or exhausted node pools. Node conditions, pod readiness and Kubernetes events, viewed together, explain whether to scale the pool or fix requests and limits.
Configuration changes. Many incidents follow a change: a new deployment slot swap, a scaled-down plan or an updated network rule. Activity Log events on the same timeline as metrics make these changes visible.
Azure monitoring best practices
- Use consistent tags and resource group conventions so dashboards and alerts can be scoped by team, service and environment.
- Connect every subscription, including non-production, through one read-only service principal or management group assignment.
- Alert on user-facing symptoms such as error rate and response time, and keep resource alerts for capacity planning.
- Instrument .NET, Java, Node.js and Python apps with OpenTelemetry so traces cross App Service, Functions and AKS boundaries.
- Track changes and deployments next to metrics to shorten the time to root cause.
How Obseria monitors Azure
Obseria connects agentlessly through a service principal with read-only roles and collects Azure Monitor metrics and resource metadata for VMs, AKS, App Service, Functions, Azure SQL and many more services, as part of 300+ cloud services across AWS, Azure and Google Cloud. The Obseria Agent adds guest-level and Kubernetes data, and OpenTelemetry traces and logs arrive over OTLP. Obseria TopoGraph builds the dependency map automatically, and Obseria Intelligence uses it to investigate incidents with a chain of evidence. Dashboards, alerts and SLOs are included, and data can stay in the EU region.
Related integrations
Related capabilities
Cloud Monitoring
Monitor 300+ cloud services agentless and see how they affect your applications. One platform for multi-cloud metrics, logs, traces and topology.
Learn moreKubernetes Monitoring
See every cluster, node, pod and workload in context. Obseria connects Kubernetes metrics, events, logs and traces so you find the cause of a failing rollout in minutes.
Learn moreServerless Monitoring
Trace every invocation across functions, queues and APIs. Obseria shows cold starts, errors, duration and cost for serverless workloads in the context of your whole system.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
The four golden signals: latency, traffic, errors and saturation
The four golden signals explained: latency, traffic, errors and saturation, how they relate to the RED and USE methods, and how to measure them with OTel.
Azure monitoring FAQ
Obseria reads platform metrics from Azure Monitor and combines them with traces, logs and data from other clouds. Many teams keep Azure Monitor as the source and use Obseria for cross-service analysis, alerting and root cause.
Read-only roles are sufficient: Monitoring Reader for metrics and Reader for resource and tag discovery, assigned at subscription or management group scope.
AKS platform metrics are collected agentlessly. For node, pod and container detail, install the Obseria Agent as a DaemonSet with the Helm chart, or send data from an OpenTelemetry Collector.
Yes. Use the OpenTelemetry SDK for your language and set OTEL_SERVICE_NAME and OTEL_EXPORTER_OTLP_ENDPOINT in the app settings. Traces then link function invocations and web requests to downstream calls.
Yes. You can choose the EU region (Frankfurt, Dublin), the UK region (London) or your own cloud account (BYOC).
Start monitoring Azure today
Connect Azure in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.