Windowsperfcounters Receiver
contrib
Maintainers: @dashpole, @alxbl, @pjanotti
Source: opentelemetry-collector-contrib
Supported Telemetry
Overview
This receiver is based on the Telegraf Windows Performance Counters Input Plugin. If one of the specified performance counters cannot be loaded on startup, a warning will be printed, but the application will not fail fast. It is expected that some performance counters may not exist on some systems due to different OS configuration.Configuration
The collection interval and the list of performance counters to be scraped can be configured:Understanding the instances configuration option
| Value | Interpretation |
|---|---|
| Not specified | This is the only valid value if the counter has no instances. |
"*" | All instances, excluding _Total. |
"_Total" | The “total” instance, that aggregates the values of all other instances. See below for its special treatment. |
"instance1" | A single instance. |
["instance1", "instance2", ...] | A set of instances. |
Aggregation counter and the behavior of the _Total instance
The _Total must be collected individually on its own metric,
since it is dropped when collected together with other instances.
[!WARNING] When using the"*"forinstances, check what is the aggregation instance used by the counter. If the counter uses something other than_Total, e.g.:_Global_, special care is needed to avoid double-counting when aggregating the metrics after they are scraped by the receiver.
Recreating the query on every scrape
On some versions of Windows, Counters are sometimes corrupted and continuously return invalid data after the first scrape. When/If this happens, it is possible to set the counter settingrecreate_query to true (defaults to false) to tell
the receiver to recreate the PDH query on every scrape. This has slight
performance implications but should be inconsequential unless
collection_interval is very aggressive.
If re-creating the query fails, the previous query will be re-used and an error
will be logged.
Scraping at different frequencies
If you would like to scrape some counters at a different frequency than others, you can configure multiplewindowsperfcounters receivers with different
collection_interval values. For example:
Defining metric format
To report metrics in the desired output format, define a metric and reference it in the corresponding counter, along with any applicable attributes. The metric’s data type can either begauge (default) or sum.
| Field Name | Description | Value | Default |
|---|---|---|---|
| name | The key for the metric. | string | Counter Name |
| description | definition of what the metric measures. | string | |
| unit | what is being measured. | string | 1 |
| sum | representation of a sum metric. | Sum Config | |
| gauge | representation of a gauge metric. | Gauge Config |
Sum Config
| Field Name | Description | Value | Default |
|---|---|---|---|
| aggregation | The type of aggregation temporality for the metric. | [cumulative or delta] | |
| monotonic | whether or not the metric value can decrease. | false |
Gauge Config
Agauge config currently accepts no settings. It is specified as an object for forwards compatibility.
e.g. To output the Memory/Committed Bytes counter as a metric with the name
bytes.committed:
Known Limitation
-
The network interface is not available inside the container. Hence, the metrics for the object
Network Interfacearen’t generated in that scenario. In the case of sub-process, it capturesNetwork Interfacemetrics. There is a similar open issue in GitHub and Docker forum. -
The counter category
Processis unreliable with multiple instances of the same process. On Windows 11 and later, it is recommended to useProcess V2instead as it includes the process ID in the instance name. For versions prior to Windows 11 it is possible to configure theProcesscounter category to include the PID in the instance name.
Configuration
Example Configuration
Last generated: 2026-04-13