# prometheus-community/windows_exporter: WMI metrics from a Windows box

> A Go exporter that turns Windows management counters into Prometheus metrics, with around thirty opt-in collectors for Active Directory, IIS, Hyper-V, Message Queue and the rest of the server role list.

**prometheus-community/windows_exporter** — Prometheus exporter for Windows machines

- Repository: https://github.com/prometheus-community/windows_exporter
- Stars: 3,651 · Forks: 783
- Language: Go
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/prometheus-community-windows-exporter

## Collectors are opt-in because most Windows roles are absent

The README's collector table is the documentation. Each row names a collector, links a page under `docs/` describing it, and marks whether it is enabled by default. Scanning the enabled column is the fastest way to understand the defaults: CPU usage, logical disk and memory are on, and everything else is off.

That default is a considered choice rather than laziness. Most of these collectors query role-specific WMI namespaces, and on a machine that does not host Active Directory or IIS or Hyper-V, enabling them means a scrape that walks a namespace and finds nothing. With around thirty collectors available, running all of them everywhere would add scrape latency to every host in exchange for metrics that only exist on some.

The list also shows what this exporter is for. It is not a generic system metrics exporter; it reaches into the Windows server product catalogue. Visible in the table are Active Directory Domain Services, Certificate Services and Federation Services, DHCP, DNS, Exchange, File Server Resource Manager quotas, GPU, Hyper-V, IIS sites and applications, MSCluster, Message Queuing, cache, and logical disk with disk I/O.

Every collector has its own documentation page, which is the right level of detail for something where metric names differ per role and availability depends on the Windows SKU.

## go-ole is the dependency that explains the architecture

The module requires `go-ole`, which is the Go binding for COM. That single line explains most of the design: Windows management instrumentation is COM-based, so the exporter has to drive a COM interface rather than read a file or call a Linux-style syscall wrapper.

The rest of the direct dependencies are recognisable for any Prometheus exporter. `prometheus/client_golang` and `client_model` for metric construction, `prometheus/common` and `exporter-toolkit` for the standard serving and web configuration machinery, `kingpin/v2` for flag parsing, `stretchr/testify` for tests, and `golang.org/x/sys` for the platform layer. `go.mod` declares Go 1.26.0, and the metric and toolkit versions are recent, which matters because exporter-toolkit carries the web configuration surface that handles TLS and authentication.

Indirect dependencies reveal the transport side. `mdlayher/socket` and `vsock` are there for vsock, which is how a HostProcess or a Windows container reaches its host without a network hop, and `coreos/go-systemd/v22` shows the exporter participates in the usual service-management conventions.

The README stays out of these details, which is appropriate, and the repository tree reflects a conventional exporter layout: `cmd/` for the binary entry point, `pkg/` for the public packages, `internal/` for the collector implementations, plus `installer/`, `kubernetes/`, `dashboard/` and a `config.yaml` at the root.

## Building runs promu, and tests run through PowerShell

The Makefile is the practical documentation. The build target depends on a generate step and produces `windows_exporter.exe`, with the build itself delegated to promu:

```bash
promu build -v
```

`GOOS` defaults to `windows`, which is a reminder that this binary is not portable to anywhere else and that cross-compiling is the only route to a release artefact.

Cross-compilation is handled explicitly rather than left to CI. The `crossbuild` target runs `promu build` twice with `GOARCH=amd64` and `GOARCH=arm64`, writing to `output/amd64` and `output/arm64`, and a comment explains why: the prometheus golang-builder image used for crossbuild does not exist on Windows, so the project builds twice instead. That is the kind of note that saves someone an afternoon.

The Windows image matrix is also pinned in the Makefile, with `OS` set to `ltsc2019` and `ALL_OS` covering `ltsc2019 ltsc2022`. Tests run through PowerShell scripts with execution policy bypassed:

```bash
powershell -NonInteractive -ExecutionPolicy Bypass -File .\tools\end-to-end-test.ps1
```

There is also a `promtool` target wired to `tools/promtool.ps1`, which suggests the project checks its own metric output against Prometheus's own tooling rather than trusting that the exposition format is valid.

## The container image is a HostProcess container, not Server Core

The Dockerfile is short and its base image is the interesting part. It builds on Microsoft's HostProcess containers base image, and a comment at the top explains why that is preferable to a normal Windows container image: smaller size, and OS compatibility across any Windows version that supports containers.

The consequence for a HostProcess container is that it shares the host's kernel and so can reach host metrics directly, which is the point for an exporter. The image then copies the amd64 executable and sets it as the entrypoint:

```dockerfile
FROM $BASE

COPY windows_exporter*-amd64.exe /windows_exporter.exe
ENTRYPOINT ["windows_exporter.exe"]
```

The build has one non-obvious constraint, stated in the Dockerfile comments: this image must be built with `docker buildx build` on a Linux system, not on the Windows host itself. That trips people up the first time.

The Makefile also tracks that `ghcr.io` requires the organisation name to match the image name, so the push list is `docker.io/prometheuscommunity` plus `ghcr.io/prometheus-community`, with `quay.io` commented out. Docker image variables are also set for the container image path, alongside the older nanoserver base image reference.

## Recent releases are dependency maintenance, not new collectors

The version line tells you what phase the project is in. v0.31.8, published on 2026-07-22, is almost entirely dependency updates: `mdlayher/socket` and `mdlayher/vsock` bumps, `golang.org/x` updates, and an exporter-toolkit move to v0.16.0. Renovate does the work, and each entry carries a `(0.31)` release-track suffix, which is how the project marks a change as belonging to a maintenance line rather than to the next minor.

The two releases before it are single fixes, which tells you the exporter itself is stable. v0.31.7 from 2026-05-14 updates the Go version to the latest 1.25.x. v0.31.6 from 2026-04-01 fixes deserialization of an HNS response in the container collector's `GetHNSEndpointStats`, contributed from outside the core team.

Taken together, the history says the collector set is complete enough that the work is keeping up with dependencies and fixing the occasional container-metric bug, not adding coverage. That is what you want from a component that runs on every Windows host in an estate.

GitHub reports the last push on 2026-09-10 and the repository is not archived, on the `master` branch. The README's badge set covers CI, linting, the current release, the Go Report Card and the licence, and `CONTRIBUTING.md`, `SECURITY.md`, `MAINTAINERS.md` and `CODE_OF_CONDUCT.md` fill out the governance files.

## Conclusion

windows_exporter does the unglamorous work that makes Windows hosts visible to Prometheus, and it does it in a way that respects the shape of Windows: each metric source is a collector you enable by name, and most of them are off by default because querying an absent role wastes a scrape. The design decisions worth knowing are in the packaging rather than the metric list. It targets Go 1.26 in `go.mod`, it depends on `go-ole` for the COM layer that WMI sits on, and its Dockerfile is built on Microsoft's HostProcess containers base image rather than a Server Core image, which is why the Makefile cross-compiles for amd64 and arm64 and targets `ltsc2019` and `ltsc2022`. Version 0.31.8 came out on 2026-07-22 and GitHub reports the last push on 2026-09-10. If you want the quickest path, build with `make build` which runs `promu`, start it with the collectors you need, and confirm with a scrape of the metrics endpoint rather than assuming the WMI counters exist on your SKU.

## FAQ

### What is Prometheus Exporter and what is it used for?

An exporter is a small program that turns metrics from a system into the Prometheus exposition format so a Prometheus server can scrape it. windows_exporter is that program for Windows, exposing CPU, memory and disk by default and offering opt-in collectors for roles such as Active Directory, IIS, Hyper-V and DNS Server.

### Which collectors are enabled by default?

Only three are marked enabled by default in the README table: cpu for CPU usage, logical_disk for logical disks and disk I/O, and memory for memory usage metrics. Every other collector, including the Active Directory, Exchange, Hyper-V and IIS ones, has to be switched on explicitly by name.

### How do I build windows_exporter from source?

Run `make build`, which executes `go generate ./...` and then `promu build -v` to produce `windows_exporter.exe`, with `GOOS` defaulting to windows. For a release artefact use the `crossbuild` target, which builds amd64 and arm64 separately because the prometheus golang-builder image is not available on Windows.

### Can windows_exporter run in a container?

The Dockerfile builds on Microsoft's HostProcess containers base image and copies the amd64 binary in as the entrypoint, and the image must be built with `docker buildx build` on a Linux system. The Makefile targets the `ltsc2019` and `ltsc2022` Windows versions and pushes to docker.io and ghcr.io.

## Sources

- [Issues](https://github.com/prometheus-community/windows_exporter/issues)
- [License: MIT](https://github.com/prometheus-community/windows_exporter/blob/master/LICENSE)
- [prometheus-community/windows_exporter on GitHub](https://github.com/prometheus-community/windows_exporter)
- [README](https://github.com/prometheus-community/windows_exporter/blob/master/README.md)
- [Releases](https://github.com/prometheus-community/windows_exporter/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prometheus-community-windows-exporter