Splunk online course

Collect Windows Performance Counters in Splunk

Learn how to configure Splunk to collect local or remote Windows Performance Monitor counters, select objects and instances, set polling intervals, and verify indexed data.

Splunk can collect performance counters exposed through Windows Performance Monitor. These counters are time-series measurements that describe operating-system, hardware, and application behavior over time. Examples include processor activity, disk usage, network activity, memory pressure, and process measurements.

Collected counter data provides operational visibility, supports trend and capacity analysis, and helps identify sustained or changing performance conditions that could contribute to service interruption.

Performance counters, objects, and instances

A performance counter is a Windows metric that reports a measurable aspect of system performance over time. Windows Performance Monitor exposes related measurements in a hierarchy:

  • Performance object: A category of related counters, such as Processor.
  • Counter: A specific measurement within an object, such as a processor-time measurement.
  • Instance: A particular entity to which a counter applies, such as an individual processor, disk, network adapter, process, or service instance.
  • _Total: An aggregate instance representing total processor time across all processors.

Object | Category of related measurements | Processor

Counter | Specific measurement | Processor-time measurement

Instance | Monitored entity | _Total

A Splunk performance-monitoring data input can select only one performance object. You can select one or more counters and instances from that object. If you need counters from multiple objects, create separate inputs.

Local and remote performance monitoring

Local collection reads counters from the Windows computer where Splunk is running. This collection method requires Splunk to run as the built-in Local System user.

Remote collection reads counters from another Windows computer. Splunk must run under a domain account or remote-user account with at least read permission to WMI on the target computer. The target must also be reachable over the network, and Windows Management Instrumentation, or WMI, must be available and accessible.

Collection location | Splunk execution identity | Target access requirement | Key dependency

Local Windows host | Local System user | Local counter access | Splunk service identity

Remote Windows host | Domain or remote-user account | At least WMI read access on the target | Network and WMI connectivity

Service-account considerations

Changing the Splunk Windows service account changes the identity used to collect data. A change that enables remote collection can prevent local collection if the new identity does not meet the local requirements for this collection method. Before changing the account, document the existing configuration, grant only the permissions required for the monitoring scope, and test both local and remote access.

For remote monitoring, validate the account on the target Windows computer rather than assuming that a successful Splunk login grants WMI access. Least-privilege access reduces operational and security risk.

Create a local performance-monitoring input

  1. In Splunk Web, open Settings.
  2. Open Data inputs.
  3. Choose Local performance monitoring.
  4. Choose New to create a collection configuration.
  5. Enter a meaningful collection name, such as web01_cpu_total or database_disk_activity. Use a name that identifies the host role or metric set.

The exact form can vary slightly by Splunk version and permissions, but the configuration decisions remain the same.

Select the performance object

Use the available performance-object list to choose the Windows Performance Monitor object to collect. For example, choose Processor for processor measurements.

Only one performance object can be selected in each performance-monitoring data input. To collect processor, memory, and disk objects, create separate inputs. Separating objects makes collection names, indexes, searches, and dashboards easier to organize.

Select counters and instances

After selecting an object, choose one or more counters belonging to that object. Then select the instances that should be monitored.

Instances identify individual monitored entities. Depending on the object, an instance might represent a processor, disk, network adapter, process, or service. Select an individual instance when you need detailed per-entity behavior. Select an aggregate instance when the monitoring goal is an overall view.

For processor monitoring, the _Total instance represents aggregate processor time across all processors. It is useful for a high-level view of combined CPU activity. Individual processor instances are useful when you need to identify an imbalance or a problem affecting only part of the system.

Example: aggregate processor utilization

  1. Create a local performance-monitoring input.
  2. Name it for the CPU use case, such as web01_cpu_total.
  3. Select the Processor object.
  4. Choose the processor-time counter appropriate to the monitoring objective.
  5. Select the _Total instance to capture combined activity across all processors.
  6. Set the polling interval, app context, host value, and destination index.
  7. Submit the input and search the selected index to confirm that measurements arrive.

Configure the polling interval

The polling interval is the number of seconds between collection attempts. Choose an interval that matches the operational question.

  • A shorter interval captures more detail and makes brief spikes easier to observe, but it increases event volume, storage use, and collection overhead.
  • A longer interval reduces event volume and overhead, but brief spikes may be missed and charts will contain fewer measurements.

For capacity planning, a moderate interval may be sufficient. For investigating short-lived saturation, a shorter interval may be appropriate. Avoid collecting every available counter and instance without a defined use case.

Set the app context, host, and index

Configure the remaining data context and destination fields:

  • App context: The Splunk app namespace in which the input is created or managed.
  • Host value: The Splunk metadata value identifying the host associated with each event.
  • Index: The Splunk data store where the performance events are written.

Use a consistent host value and index strategy. Consistent host metadata makes searches reliable, while intentional index assignment simplifies retention administration and dashboard design. If an index does not yet exist, create it before configuring the input; see Create An Index.

Setting | Purpose | Key guidance

Collection name | Identifies the input | Name it for the host role or metric set

Performance object | Selects the counter category | Select exactly one object per input

Counters | Selects measurements | Choose one or more counters from the object

Instances | Selects monitored entities | Use individual instances or an aggregate such as _Total

Polling interval | Sets seconds between collection attempts | Balance detail against volume and overhead

App context | Defines the Splunk namespace | Use the intended app for administration and searches

Host value | Identifies the source host | Keep naming consistent

Index | Stores the events | Use an index with suitable access and retention settings

Review and submit the input

Before creating the input, review the complete configuration:

  • Collection name
  • Performance object
  • Counters
  • Instances, including whether _Total is required
  • Polling interval in seconds
  • App context
  • Host value
  • Destination index

Submit the configuration to enable collection. Confirm that the input is enabled and begins polling. For a remote target, also confirm that the service account, network path, and WMI permissions are correct.

Search and analyze collected data

Start validation with the configured host and index. Replace the example values with the values used by your input:

index=<performance_index> host=<configured_host>

Narrow the results with the collection name, performance object, counter, or instance identifiers when those fields or values are present in the indexed events:

index=<performance_index> host=<configured_host> "Processor" "_Total"

Use the time range picker to inspect a suitable period. Search results should show measurements arriving at the expected polling frequency. Then compare values over time to recognize saturation, sustained resource usage, recurring peaks, and changes in system behavior. Search and field behavior can be explored in Launch Search App, Fields, and Time Range Picker.

Counter data supports ongoing health monitoring by showing whether a resource is approaching a known operating limit or behaving differently from its normal baseline. Combined with logs and alerts, these trends can help teams investigate conditions before they cause downtime. Related Windows collection methods are covered in Collect Event Logs From A Local Windows Machine and Collect Windows Host Information.

Example: collect data from a remote Windows host

  1. Run Splunk under an appropriate domain or remote-user identity.
  2. Verify that the account has at least read permission to WMI on the target Windows computer.
  3. Confirm network reachability and that WMI is available on the target.
  4. Configure the performance object, counters, instances, polling interval, app context, host value, and index.
  5. Submit the input and search the selected index and remote host value.
  6. Confirm that events from the remote system appear and that their metadata identifies the intended source.

Remote monitoring depends on service-account permissions and WMI access, not only on the selections in the Splunk input form.

Separate inputs for different resource types

Suppose an operations team needs processor, disk, and network data. Create one input for the Processor object, another for the disk-related object, and another for the network-related object. Give each input an intentional name and, where useful, an intentional index assignment. Separate inputs make it easier to tune intervals, restrict counters, and compare results in searches or dashboards.

Troubleshooting

No data appears after creating a local input

  • Verify that the Splunk Windows service runs as the Local System user.
  • Check that the input was submitted, is enabled, and points to the intended index.
  • Confirm that the selected performance object, counters, and instances exist on the local host.
  • Search with the configured host and index rather than relying only on a broad search.

Remote collection fails or returns no results

  • Confirm that Splunk runs under a domain or remote-user account with WMI read access on the target.
  • Validate network reachability to the remote Windows computer.
  • Confirm that WMI is functioning and available on the target.
  • Recheck the configured host value and destination index.

Processor-wide values are missing

  • Review the selected instances. An individual processor instance may have been selected instead of _Total.
  • Use _Total when the objective is aggregate processor time across all processors.
  • Confirm that the Processor object and intended processor-time counter were selected.

Data volume is too high or charts lack detail

  • Review the polling interval in seconds.
  • Use a shorter interval when brief spikes matter, and a longer interval when trend data is sufficient.
  • Limit collection to counters and instances that support the monitoring objective.

Exam-relevant notes

  • Local performance collection requires the Splunk service to run as Local System.
  • Remote performance collection requires a domain or remote-user identity with at least WMI read access on the target, plus network and WMI connectivity.
  • Each performance-monitoring data input selects only one performance object.
  • Counters are measurements; instances identify the entities being measured.
  • _Total represents aggregate processor time across all processors.
  • Shorter polling intervals increase detail and data volume; longer intervals reduce both and can miss brief spikes.
  • Consistent host and index values improve searchability, retention administration, and dashboard design.