Convert Figma logo to code with AI

prometheus-community logowindows_exporter

Prometheus exporter for Windows machines

2,849
680
2,849
24

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

  1. Download the latest release from the GitHub releases page.

  2. 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
  1. Start the service:
Start-Service windows_exporter
  1. Add the following job to your Prometheus configuration:
scrape_configs:
  - job_name: 'windows'
    static_configs:
      - targets: ['<windows-host>:9182']
  1. 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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

windows_exporter

Build Status

A Prometheus exporter for Windows machines.

Collectors

NameDescriptionEnabled by default
adActive Directory Domain Services
adcsActive Directory Certificate Services
adfsActive Directory Federation Services
cacheCache metrics
cpuCPU usage
cpu_infoCPU Information
cs"Computer System" metrics (system properties, num cpus/total memory)
containerContainer metrics
diskdriveDiskdrive metrics
dfsrDFSR metrics
dhcpDHCP Server
dnsDNS Server
exchangeExchange metrics
fsrmquotaMicrosoft File Server Resource Manager (FSRM) Quotas collector
hypervHyper-V hosts
iisIIS sites and applications
licenseWindows license status
logical_diskLogical disks, disk I/O
logonUser logon sessions
memoryMemory usage metrics
msclusterMSCluster metrics
msmqMSMQ queues
mssqlSQL 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
netNetwork interface I/O
osOS metrics (memory, processes, users)
physical_diskphysical disk metrics
printerPrinter metrics
processPer-process metrics
remote_fxRemoteFX protocol (RDP) metrics
scheduled_taskScheduled Tasks metrics
serviceService state metrics
smbSMB Server
smbclientSMB Client
smtpIIS SMTP Server
systemSystem calls
tcpTCP connections
teradici_pcoipTeradici PCoIP session metrics
timeWindows Time Service
thermalzoneThermal information
terminal_servicesTerminal services (RDS)
textfileRead prometheus metrics from a text file
vmware_blastVMware Blast session metrics
vmwarePerformance 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.

FlagDescriptionDefault value
--web.listen-addresshost:port for exporter.:9182
--telemetry.pathURL path for surfacing collected metrics./metrics
--telemetry.max-requestsMaximum number of concurrent requests. 0 to disable.5
--collectors.enabledComma-separated list of collectors to use. Use [defaults] as a placeholder which gets expanded containing all the collectors enabled by default."[defaults]
--collectors.printIf true, print available collectors and exit.
--scrape.timeout-marginSeconds to subtract from the timeout allowed by the client. Tune to allow for overhead or high loads.0.5
--web.config.fileA web config for setting up TLS and AuthNone
--config.fileUsing a config file from path or URLNone
--config.file.insecure-skip-verifySkip TLS when loading config file from URLfalse

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:

NameDescription
ENABLED_COLLECTORSAs the --collectors.enabled flag, provide a comma-separated list of enabled collectors
LISTEN_ADDRThe IP address to bind to. Defaults to an empty string. (any local address)
LISTEN_PORTThe port to bind to. Defaults to 9182.
METRICS_PATHThe path at which to serve metrics. Defaults to /metrics
TEXTFILE_DIRSUse the --collector.textfile.directories flag to specify one or more directories, separated by commas, where the collector should read text files containing metrics
REMOTE_ADDRAllows setting comma separated remote IP addresses for the Windows Firewall exception (allow list). Defaults to an empty string (any remote address).
EXTRA_FLAGSAllows passing full CLI flags. Defaults to an empty string.
ADDLOCALEnables features within the windows_exporter installer. Supported values: FirewallException
REMOVEDisables 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

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