September 2026 release is live Read More

K8s Prometheus on Windows (AKS)

Why this matters: AKS Windows node pools don't come with Prometheus/Windows Exporter support out of the box the way Linux nodes do — this is the workaround for getting CPU/memory/disk metrics off Windows nodes so Mavvrik (and Prometheus generally) can see them at all.

  1. Create a Kubernetes (K8s) cluster on Azure (AKS), making sure it has System & User Linux Node to provision necessary Prometheus-related pods.

  2. Install helm on the cluster, then connect to the k8s cluster.

  3. First, taint the Windows node so that no Linux pods are provisioned on this node:

kubectl taint nodes akswinbil000000 os=windows:NoSchedule
Apply the Windows node scheduling taint
Apply the Windows node scheduling taint
  1. Add and update the Prometheus community helm repository:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 
helm repo update
  1. Install Prometheus using Helm only on Linux nodes:

helm install prometheus prometheus-community/prometheus \\n  --namespace monitoring \\n  --create-namespace \\n  --set nodeSelector."kubernetes\.io/os"=linux

After this you will see Prometheus pods running successfully on Linux nodes only

Verify Prometheus pods are running on Linux nodes
Verify Prometheus pods are running on Linux nodes

b. Install Windows Exporter on the k8s cluster to monitor Windows nodes

** This image is for Windows 2022 Datacenter: http://ghcr.io/prometheus-community/windows-exporter:0.29.0-ltsc2022

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: windows-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: windows-exporter
  template:
    metadata:
      labels:
        app: windows-exporter
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      tolerations:
      - key: "os"
        operator: "Equal"
        value: "windows"
        effect: "NoSchedule"
      hostNetwork: true
      securityContext:
        windowsOptions:
          hostProcess: true
          runAsUserName: "NT AUTHORITY\\System"
      containers:
      - name: windows-exporter
        image: ghcr.io/prometheus-community/windows-exporter:0.29.0-ltsc2022
        ports:
        - containerPort: 9182
          hostPort: 9182
          name: http
        args:
        - --collectors.enabled=cpu,cs,container,logical_disk,memory,net,os


Deploy the Windows Exporter DaemonSet
Deploy the Windows Exporter DaemonSet

c. Install windows-exporter service

apiVersion: v1
kind: Service
metadata:
  name: windows-exporter-svc
  namespace: monitoring
spec:
  selector:
    app: windows-exporter  # Must match labels in your DaemonSet pods
  ports:
    - name: http
      port: 9182
      targetPort: 9182
  type: ClusterIP
Create the Windows Exporter service
Create the Windows Exporter service

c. Update the Prometheus config map to scrape Windows-exporter metrics. Under the scrape config, add the following configuration.

    scrape_configs:
    - job_name: 'windows_node'
      static_configs:
      - targets:
        - 'windows-exporter-svc.monitoring.svc.cluster.local:9182'

Access the Prometheus UI to see Windows metrics like:

View Windows metrics in Prometheus
View Windows metrics in Prometheus

Troubleshooting

  • If Prometheus pods fail to come up, confirm the cluster has System & User Linux node pools available — Prometheus itself is installed only on Linux nodes, not the Windows node.

  • If Windows metrics aren't showing up in Prometheus, confirm the taint was applied to the Windows node and the scrape config target matches the windows-exporter-svc service name and port exactly.

FAQs

Why does this setup taint the Windows node?
To prevent Linux pods — including Prometheus itself — from being scheduled onto it. Prometheus runs only on Linux nodes here; the Windows Exporter DaemonSet is what actually collects metrics from the Windows node.

Does this work for any Windows Server version?
The image referenced (windows-exporter:0.29.0-ltsc2022) is specifically for Windows Server 2022 Datacenter. A different Windows version would need a matching image tag.