Top Related Projects
Exporter for machine metrics
Prometheus exporter for Windows machines
Prometheus exporter that mines /proc to report on selected processes
Quick Overview
Windows Exporter is a Prometheus exporter for Windows machines, designed to collect and expose various metrics from Windows systems. It provides a wide range of collectors for different aspects of Windows, including CPU, memory, disk, network, and more, making it an essential tool for monitoring Windows environments with Prometheus.
Pros
- Comprehensive coverage of Windows-specific metrics
- Highly configurable with numerous collectors available
- Active community and regular updates
- Easy integration with existing Prometheus setups
Cons
- Limited to Windows environments
- Some collectors may have performance impacts on heavily loaded systems
- Configuration can be complex for advanced scenarios
- Requires administrative privileges for full functionality
Getting Started
-
Download the latest release from the GitHub releases page.
-
Install the exporter as a Windows service:
.\windows_exporter-<version>-amd64.exe --collectors.enabled="cpu,memory,disk,logon,os,system" --collector.service.services-where="Name='windows_exporter'" install
- Start the service:
Start-Service windows_exporter
- Add the following job to your Prometheus configuration:
scrape_configs:
- job_name: 'windows'
static_configs:
- targets: ['<windows-host>:9182']
- Restart Prometheus to apply the changes.
Competitor Comparisons
Exporter for machine metrics
Pros of node_exporter
- Broader platform support, including various Unix-like systems
- More mature project with a larger community and extensive documentation
- Wider range of metrics and collectors available out-of-the-box
Cons of node_exporter
- Limited Windows support (requires WSL or Cygwin)
- May require additional configuration for Windows-specific metrics
- Less optimized for Windows environments compared to windows_exporter
Code Comparison
node_exporter:
func (c *cpuCollector) Update(ch chan<- prometheus.Metric) error {
if time.Since(c.cpu.Time) < minCollectInterval {
return nil
}
stats, err := c.cpu.Get()
if err != nil {
return err
}
// ... (metric collection logic)
}
windows_exporter:
func (c *CPUCollector) Collect(ch chan<- prometheus.Metric) error {
var dst []Win32_PerfFormattedData_PerfOS_Processor
q := wmi.CreateQuery(&dst, "")
if err := wmi.Query(q, &dst); err != nil {
return err
}
// ... (metric collection logic)
}
The code snippets show different approaches to collecting CPU metrics, with windows_exporter using Windows-specific WMI queries, while node_exporter uses a more generic approach suitable for Unix-like systems.
Prometheus exporter for Windows machines
Pros of windows_exporter
- Actively maintained and regularly updated
- Extensive documentation and community support
- Wide range of Windows-specific metrics collected
Cons of windows_exporter
- Potentially higher resource usage due to comprehensive metric collection
- May require more configuration for specific use cases
Code Comparison
Both repositories contain the same codebase, as they are the same project. Here's a sample of the main.go file from windows_exporter:
func main() {
var (
listenAddress = kingpin.Flag("web.listen-address", "Address on which to expose metrics and web interface.").Default(":9182").String()
metricsPath = kingpin.Flag("web.telemetry-path", "Path under which to expose metrics.").Default("/metrics").String()
enabledCollectors = kingpin.Flag("collectors.enabled", "Comma-separated list of collectors to use.").Default(defaultCollectors).String()
printCollectors = kingpin.Flag("collectors.print", "If true, print available collectors and exit.").Bool()
)
As both repositories are identical, there are no differences in the code to compare.
Prometheus exporter that mines /proc to report on selected processes
Pros of process-exporter
- Focuses specifically on process metrics, providing more detailed process-level information
- Works across multiple operating systems (Linux, Windows, macOS)
- Allows for custom process grouping and naming
Cons of process-exporter
- Limited to process-related metrics only
- Requires more configuration to set up process grouping and naming
- Less actively maintained compared to windows_exporter
Code Comparison
process-exporter configuration example:
process_names:
- name: "{{.Comm}}"
cmdline:
- '.+'
windows_exporter configuration example:
collectors:
enabled: ["process"]
Summary
process-exporter is a specialized tool for collecting detailed process metrics across multiple operating systems, offering custom grouping and naming. However, it's limited to process-related metrics and requires more configuration.
windows_exporter is a more comprehensive Windows-specific exporter that covers a wide range of metrics beyond just processes. It's more actively maintained and easier to set up for basic process monitoring, but lacks the cross-platform support and detailed process grouping features of process-exporter.
Choose process-exporter for detailed, customizable process monitoring across different operating systems. Opt for windows_exporter for a broader range of Windows-specific metrics with simpler configuration.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
windows_exporter
A Prometheus exporter for Windows machines.
Collectors
Name | Description | Enabled by default |
---|---|---|
ad | Active Directory Domain Services | |
adcs | Active Directory Certificate Services | |
adfs | Active Directory Federation Services | |
cache | Cache metrics | |
cpu | CPU usage | ✓ |
cpu_info | CPU Information | |
cs | "Computer System" metrics (system properties, num cpus/total memory) | |
container | Container metrics | |
diskdrive | Diskdrive metrics | |
dfsr | DFSR metrics | |
dhcp | DHCP Server | |
dns | DNS Server | |
exchange | Exchange metrics | |
fsrmquota | Microsoft File Server Resource Manager (FSRM) Quotas collector | |
hyperv | Hyper-V hosts | |
iis | IIS sites and applications | |
license | Windows license status | |
logical_disk | Logical disks, disk I/O | ✓ |
logon | User logon sessions | |
memory | Memory usage metrics | |
mscluster | MSCluster metrics | |
msmq | MSMQ queues | |
mssql | SQL Server Performance Objects metrics | |
netframework_clrexceptions | .NET Framework CLR Exceptions | |
netframework_clrinterop | .NET Framework Interop Metrics | |
netframework_clrjit | .NET Framework JIT metrics | |
netframework_clrloading | .NET Framework CLR Loading metrics | |
netframework_clrlocksandthreads | .NET Framework locks and metrics threads | |
netframework_clrmemory | .NET Framework Memory metrics | |
netframework_clrremoting | .NET Framework Remoting metrics | |
netframework_clrsecurity | .NET Framework Security Check metrics | |
net | Network interface I/O | ✓ |
os | OS metrics (memory, processes, users) | ✓ |
physical_disk | physical disk metrics | ✓ |
printer | Printer metrics | |
process | Per-process metrics | |
remote_fx | RemoteFX protocol (RDP) metrics | |
scheduled_task | Scheduled Tasks metrics | |
service | Service state metrics | ✓ |
smb | SMB Server | |
smbclient | SMB Client | |
smtp | IIS SMTP Server | |
system | System calls | ✓ |
tcp | TCP connections | |
teradici_pcoip | Teradici PCoIP session metrics | |
time | Windows Time Service | |
thermalzone | Thermal information | |
terminal_services | Terminal services (RDS) | |
textfile | Read prometheus metrics from a text file | |
vmware_blast | VMware Blast session metrics | |
vmware | Performance counters installed by the Vmware Guest agent |
See the linked documentation on each collector for more information on reported metrics, configuration settings and usage examples.
Filtering enabled collectors
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.
Flags
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.
Flag | Description | Default value |
---|---|---|
--web.listen-address | host:port for exporter. | :9182 |
--telemetry.path | URL path for surfacing collected metrics. | /metrics |
--telemetry.max-requests | Maximum number of concurrent requests. 0 to disable. | 5 |
--collectors.enabled | Comma-separated list of collectors to use. Use [defaults] as a placeholder which gets expanded containing all the collectors enabled by default." | [defaults] |
--collectors.print | If true, print available collectors and exit. | |
--scrape.timeout-margin | Seconds to subtract from the timeout allowed by the client. Tune to allow for overhead or high loads. | 0.5 |
--web.config.file | A web config for setting up TLS and Auth | None |
--config.file | Using a config file from path or URL | None |
--config.file.insecure-skip-verify | Skip TLS when loading config file from URL | false |
Installation
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:
Name | Description |
---|---|
ENABLED_COLLECTORS | As the --collectors.enabled flag, provide a comma-separated list of enabled collectors |
LISTEN_ADDR | The IP address to bind to. Defaults to an empty string. (any local address) |
LISTEN_PORT | The port to bind to. Defaults to 9182 . |
METRICS_PATH | The path at which to serve metrics. Defaults to /metrics |
TEXTFILE_DIRS | Use the --collector.textfile.directories flag to specify one or more directories, separated by commas, where the collector should read text files containing metrics |
REMOTE_ADDR | Allows setting comma separated remote IP addresses for the Windows Firewall exception (allow list). Defaults to an empty string (any remote address). |
EXTRA_FLAGS | Allows passing full CLI flags. Defaults to an empty string. |
ADDLOCAL | Enables features within the windows_exporter installer. Supported values: FirewallException |
REMOVE | Disables features within the windows_exporter installer. Supported values: FirewallException |
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%'"""
Docker Implementation
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
Tags
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.
Kubernetes Implementation
See detailed steps to install on Windows Kubernetes here.
Supported versions
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.
Usage
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
Examples
Enable only service collector and specify a custom query
.\windows_exporter.exe --collectors.enabled "service" --collector.service.services-where "Name='windows_exporter'"
Enable only process collector and specify a custom query
.\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
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.
Using a configuration file
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,cs,net,service
collector:
service:
services-where: "Name='windows_exporter'"
log:
level: warn
An example configuration file can be found here.
Configuration file notes
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.
License
Under MIT
Top Related Projects
Exporter for machine metrics
Prometheus exporter for Windows machines
Prometheus exporter that mines /proc to report on selected processes
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot