Azure Health Model: Can Prometheus expressions be used?

Jan-Hendrik Peters 21 Reputation points
2026-07-20T08:08:30.6233333+00:00

The Health Model preview is quite nice so far, but lacking with regards to AKS. While we can include the node status, I have not found a good way to surface the Pod statuus.

Is support for Prometheus expressions possible or on the roadmap? Microsoft already publishes a good amount of recommended Prometheus recording and alert rules, so it would be brilliant if those could be used in a Health Model as well. Using only Log Analytics is no viable alternative, as many metrics (Pod restarts, OOM kills, ...) are not accessible or cannot easily be retrieved/calcluated.

Azure Monitor
Azure Monitor

An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.

0 comments
Answer accepted by question author
Suchitra Suregaunkar 16,780 Reputation points Microsoft External Staff Moderator
2026-07-20T18:03:42.2366667+00:00

Hello Jan-Hendrik Peters

Prometheus (PromQL) expressions are already supported in Azure Monitor health models today, so you don't have to wait for a roadmap item for this. You'll want to use the Azure Monitor workspace signal type rather than the Log Analytics one you've been trying.

How the signal types map:

Signal type Data source What it evaluates
Azure resource The resource itself Samples a platform metric and compares it against numeric thresholds
-------- -------- --------
Azure resource The resource itself Samples a platform metric and compares it against numeric thresholds
Log Analytics workspace Log Analytics workspace Runs a KQL log query and evaluates the result
Azure Monitor workspace Azure Monitor workspace Runs a PromQL query and evaluates the result

That third signal type is exactly what you need for AKS pod-level health.

What to do for your AKS scenario:

  1. Enable Managed Prometheus on the AKS cluster so metrics like kube_pod_status_phase, kube_pod_container_status_restarts_total, kube_pod_container_status_last_terminated_reason (OOMKilled), etc. are scraped into an Azure Monitor workspace. Steps are here: Enable monitoring for Azure Kubernetes Service (AKS) clusters.
  2. Add the Azure Monitor workspace as a data source on the entity representing your AKS cluster (or a child "Pods" generic entity) in the health model designer. The identity used by the health model must have permission to query metrics from that workspace.
  3. Add a signal assignment → "Create new" and paste your PromQL expression. You can reuse the recommended AKS Prometheus alert and recording rules directly here. For example:
    • Pods not Running / CrashLoopBackOff: sum by (namespace, pod) (kube_pod_status_phase{phase!="Running"})
    • OOM kills: sum by (namespace, pod) (kube_pod_container_status_last_terminated_reason{reason="OOMKilled"})
    • Restart rate: sum by (namespace, pod) (rate(kube_pod_container_status_restarts_total[5m]))
    1. Set the numeric thresholds for Healthy / Degraded / Unhealthy on the signal, and let the state roll up to your AKS or workload entity.

The end-to-end walkthrough (including the Azure Monitor workspace PromQL signal specifically) is covered in the tutorial: Configure signals in an Azure Monitor health model.

Two quick caveats worth flagging:

  • Each entity can have only one data source per signal type, but you can add multiple PromQL signals that share that same Azure Monitor workspace, so you can express pod status, restarts, and OOM kills as separate signals on the same entity and let them contribute independently to the health state.
  • The managed identity attached to the health model needs read access to the Azure Monitor workspace (Monitoring Reader is typically sufficient), otherwise the signal will show as unable to collect telemetry in the designer.

So, you don't need to fall back to Log Analytics for pod-level signals switch that entity to an Azure Monitor workspace signal and PromQL is fully available today, including the recommended Microsoft rule set.

Hope this helps! Please click "Upvote" if the provided information is helpful.

Thanks,
Suchitra.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jonathan Harrison 170 Reputation points
    2026-07-20T08:30:19.82+00:00

    I think this is more of a platform capability gap than a workload design issue.

    Health Models already support health rollups and can leverage Prometheus metrics collected from Kubernetes environments, but the challenge is that many of the most valuable AKS operational signals are typically expressed as PromQL queries, recording rules, or alert rules rather than simple metrics. [learn.microsoft.com]

    For scenarios such as pod restarts, OOM kills, crash loops, or namespace-level health, customers often already have mature Prometheus rules defined. Recreating that logic in Health Models or Log Analytics introduces duplication and additional maintenance overhead.

    Native support for:

    • PromQL expressions
    • Prometheus recording rules
    • Existing alert rules

    would allow organizations to reuse established AKS monitoring practices directly within Health Models and provide much richer Kubernetes health visibility.

    AI-based correlation through Azure AI Foundry could certainly add value by identifying patterns, anomalies, and likely root causes across Prometheus metrics, logs, and Application Insights data. However, I would see that as a complementary layer. The primary requirement here is first-class consumption of Prometheus-derived health signals inside the Health Model itself.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.