Monitoring Azure with OpenTelemetry means collecting Azure Monitor metrics and application telemetry through the OpenTelemetry Collector and OTLP, so Azure services are observed in one open pipeline..
Monitoring Azure with OpenTelemetry means collecting Azure Monitor metrics and application telemetry through the OpenTelemetry Collector and OTLP, so Azure services are observed in one open pipeline.
An Azure estate spans compute (VMs, AKS, App Service, Functions), managed data (Azure SQL, Cosmos DB), networking, and the applications on top. The goal is one correlated view: application error rate and latency, the utilization and throttling of the managed services underneath, AKS node and pod health, and cost. The recurring pattern is an application symptom whose real cause is a throttled or saturated managed service a layer down.
The practical split is to use application traces over OTLP for request latency and error attribution, and pull Azure Monitor metrics for the managed services you do not run, then correlate the two so an App Service 5xx lines up with the SQL database it depends on.
The Collector's azuremonitor receiver pulls Azure Monitor metrics for your resources, application traces and metrics arrive over OTLP (Azure Monitor's own SDKs are OpenTelemetry-based), and AKS is covered by the standard Kubernetes receivers. Everything exports over OTLP so Azure data sits beside the rest of your telemetry.
Two operational notes: pulling from Azure Monitor has a cost and a delay, so pull the resource metrics you need rather than everything, and give the Collector a service principal scoped to reading those metrics, nothing more.
Key Azure Monitor signals by service, the ones behind most incidents:
| Signal | Source | What it tells you / watch for |
|---|---|---|
Microsoft.Sql/servers: dtu_consumption_percent | azuremonitor | Azure SQL DTU/vCore saturation; the usual cause of an app that slows or errors under load. |
Microsoft.Sql/servers: connection_successful / failed | azuremonitor | Database connection health and connection-limit pressure. |
Microsoft.Web/sites: Http5xx, HttpResponseTime | azuremonitor | App Service server errors and latency; a spike points at the app or its dependencies. |
Microsoft.Web/sites: Requests | azuremonitor | App Service throughput; context for the error and latency signals. |
Microsoft.ContainerService (AKS) node/pod metrics | k8s receivers | AKS node pressure and pod restarts; same signals as any Kubernetes cluster. |
Microsoft.DocumentDB: throttled requests (429) | azuremonitor | Cosmos DB throttling from exceeding provisioned RU/s, surfacing as app errors. |
An Azure dashboard should lead from application symptom to managed-service cause. Row one is the application: error rate and p95 latency by service, from OTLP traces. Row two is the data and edge tier: Azure SQL DTU consumption and connections, App Service 5xx and response time, Cosmos DB throttling. Row three is AKS and cost: node and pod health, and daily spend by resource so a runaway cost is visible the same day.
# Azure SQL saturation (DTU/vCore percent)
Microsoft.Sql.dtu_consumption_percent by (database)
# App Service 5xx rate
Microsoft.Web.Http5xx / Microsoft.Web.Requests by (site)
# Cosmos DB throttling (429s from exceeding RU/s)
rate(Microsoft.DocumentDB.throttled_requests[5m]) by (account)An application slows or errors under load and SQL DTU (or vCore) consumption is pinned near 100%, because the database tier is the bottleneck. The DTU-percent metric is the tell. Optimise the heaviest queries, add appropriate indexes, or scale the database tier; a bigger app tier will not help.
Http5xx rises on an App Service, meaning the application is failing, often because a dependency (SQL, a downstream API) is unhealthy. Correlate the 5xx with the dependency metrics; the trace shows which downstream call failed.
Requests return 429 because they exceeded the provisioned RU/s for the container, surfacing as application errors and retries. Throttled-request count is the signal. Raise RU/s, switch to autoscale, or fix a hot partition key concentrating traffic.
Starting thresholds to tune:
| Condition | Signal | Meaning |
|---|---|---|
| SQL DTU percent > 85 for 5m | database | Database tier saturating. |
| App Service 5xx rate > 2% for 5m | edge | Application failing. |
| Cosmos 429s > 0 for 5m | database | Exceeding provisioned throughput. |
| AKS node NotReady | infra | A node has failed. |
Ops Singularity's TelemetryOps ingests Azure telemetry over OpenTelemetry and its FinOps pillar tracks Azure cost, while Sentinel AI resolves incidents through governed Action Tickets. Explore TelemetryOps.
Use the OpenTelemetry Collector's azuremonitor receiver to pull Azure Monitor metrics, and collect application traces and metrics over OTLP, since Azure Monitor's SDKs are OpenTelemetry-based.
Application error rates and latency, resource utilization and throttling on managed services, AKS node and pod health, and cost.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.