A Prometheus exporter for Windows machines.

See the linked documentation on each collector for more information on reported metrics, configuration settings and usage examples.

The windows_exporter will expose all metrics from enabled collectors by default. This is the recommended way to collect metrics to avoid errors when comparing metrics of different families.

For advanced use the windows_exporter can be passed an optional list of collectors to filter metrics. The collect[] parameter may be used multiple times. In Prometheus configuration you can use this syntax under the scrape config.

  params:
    collect[]:
      - foo
      - bar

This can be useful for having different Prometheus servers collect specific metrics from nodes.

windows_exporter accepts flags to configure certain behaviours. The ones configuring the global behaviour of the exporter are listed below, while collector-specific ones are documented in the respective collector documentation above.

The latest release can be downloaded from the releases page.

Each release provides a .msi installer. The installer will setup the windows_exporter as a Windows service, as well as create an exception in the Windows Firewall.

If the installer is run without any parameters, the exporter will run with default settings for enabled collectors, ports, etc.

The installer provides a configuration file to customize the exporter.

The configuration file

• is located in the same directory as the exporter executable.
• has the YAML format and is provided with the --config.file parameter.
• can be used to enable or disable collectors, set collector-specific parameters, and set global parameters.

The following parameters are available:

Parameters are sent to the installer via msiexec. Example invocations:

msiexec /i <path-to-msi-file> ENABLED_COLLECTORS=os,iis LISTEN_PORT=5000

Example service collector with a custom query.

msiexec /i <path-to-msi-file> ENABLED_COLLECTORS=os,service --% EXTRA_FLAGS="--collector.service.services-where ""Name LIKE 'sql%'"""

On some older versions of Windows, you may need to surround parameter values with double quotes to get the installation command parsing properly:

msiexec /i C:\Users\Administrator\Downloads\windows_exporter.msi ENABLED_COLLECTORS="ad,iis,logon,memory,process,tcp,textfile,thermalzone" TEXTFILE_DIRS="C:\custom_metrics\"

To install the exporter with creating a firewall exception, use the following command:

msiexec /i <path-to-msi-file> ADDLOCAL=FirewallException

Powershell versions 7.3 and above require PSNativeCommandArgumentPassing to be set to Legacy when using --% EXTRA_FLAGS:

$PSNativeCommandArgumentPassing = 'Legacy'
msiexec /i <path-to-msi-file> ENABLED_COLLECTORS=os,service --% EXTRA_FLAGS="--collector.service.services-where ""Name LIKE 'sql%'"""

The windows_exporter can be run as a Docker container. The Docker image is available on

• Docker Hub: docker.io/prometheuscommunity/windows-exporter
• GitHub Container Registry: ghcr.io/prometheus-community/windows-exporter

The Docker image is tagged with the version of the exporter. The latest tag is also available and points to the latest release.

Additionally, a flavor hostprocess with -hostprocess as suffix is based on the https://github.com/microsoft/windows-host-process-containers-base-image which is designed to run as a Windows host process container. The size of that images is smaller than the default one.

See detailed steps to install on Windows Kubernetes here.

windows_exporter supports Windows Server versions 2016 and later, and desktop Windows version 10 and 11 (21H2 or later).

Windows Server 2012 and 2012R2 are supported as best-effort only, but not guaranteed to work.

go get -u github.com/prometheus/promu
go get -u github.com/prometheus-community/windows_exporter
cd $env:GOPATH/src/github.com/prometheus-community/windows_exporter
promu build -v
.\windows_exporter.exe

The prometheus metrics will be exposed on localhost:9182

.\windows_exporter.exe --collectors.enabled "service" --collector.service.services-where "Name='windows_exporter'"

.\windows_exporter.exe --collectors.enabled "process" --collector.process.include="firefox.+"

When there are multiple processes with the same name, WMI represents those after the first instance as process-name#index. So to get them all, rather than just the first one, the regular expression must use .+. See process for more information.

Using [defaults] with --collectors.enabled argument which gets expanded with all default collectors.

.\windows_exporter.exe --collectors.enabled "[defaults],process,container"

This enables the additional process and container collectors on top of the defaults.

YAML configuration files can be specified with the --config.file flag. e.g. .\windows_exporter.exe --config.file=config.yml. If you are using the absolute path, make sure to quote the path, e.g. .\windows_exporter.exe --config.file="C:\Program Files\windows_exporter\config.yml"

It is also possible to load the configuration from a URL. e.g. .\windows_exporter.exe --config.file="https://example.com/config.yml"

If you need to skip TLS verification, you can use the --config.file.insecure-skip-verify flag. e.g. .\windows_exporter.exe --config.file="https://example.com/config.yml" --config.file.insecure-skip-verify

collectors:
  enabled: cpu,net,service
collector:
  service:
    services-where: "Name='windows_exporter'"
log:
  level: warn

An example configuration file can be found here.

Configuration file values can be mixed with CLI flags. E.G.

.\windows_exporter.exe --collectors.enabled=cpu,logon

log:
  level: debug

CLI flags enjoy a higher priority over values specified in the configuration file.

Under MIT