WMI input

Splunk supports WMI (Windows Management Interface) data input for agentless access to Windows performance data and event logs. This means you can pull event logs from all the Windows servers and desktops in your environment without having to install anything on those machines.

The Splunk WMI data input can connect to multiple WMI providers and pull data from them. The WMI data input runs as a separate process (splunk-wmi.exe) on the Splunk server. It is configured as a scripted input in etc/system/default/inputs.conf.

Note: This feature is NOT enabled by default. To enable it, add the following line to your etc/system/local/inputs.conf:

[script://$SPLUNK_HOME\bin\scripts\splunk-wmi.py]
disabled = 0

Security and remote access considerations

Splunk requires privileged access to index many Windows data sources, including WMI, Event Log, and the registry. This includes both the ability to connect to the box, as well as permissions to read the appropriate data once connected.

* There are several things to consider:

For remote data collection via WMI, the user the Splunk service is running as must have sufficient OS privileges to access the WMI resources you wish to poll. At a minimum, this account requires the Profile System Performance privilege and the Access this Computer from the Network privilege on every machine you wish to poll. The simplest way to ensure this is to add this user to the Performance Log Users and Distributed COM Users Domain groups. If these additions fail to provide sufficient permissions, the user the Splunk service is running as should be added to the remote machine's Administrators group.
You must enable DCOM for remote machine access, and it must be accessible to the user Splunk is running as. See the Microsoft topic about "Securing a Remote WMI Connection" for more information. Adding the user to the Distributed COM Users local group is the fastest way to enable this permission. If this fails to provide sufficient permissions, the user the Splunk service is running as should be added to the remote machine's Administrators group.
The WMI namespace that Splunk is accessing (most commonly root\cimv2) must have proper permissions set. Enable the following permissions on the WMI tree at root for the Splunk user: Execute Methods, Enable Account, Remote Enable, and Read Security. See the Microsoft how-to "HOW TO: Set WMI Namespace Security in Windows Server 2003" for more information.
The firewall, if enabled, must allow access for WMI. If you are using the Windows Firewall, the exceptions list explicitly lists WMI. You must set this exception for both the originating and the remote machine. See the Microsoft topic about "Connecting to WMI Remotely Starting with Vista" for some details.

Test access to WMI

To access WMI data, Splunk must run as a user with permissions to perform remote WMI connections. This user name must be a member of an Active Directory domain and must have appropriate privileges to query WMI. Both the Splunk server making the query and the target systems being queried must be part of this Active Directory domain.
Note: If you installed Splunk as the LOCAL SYSTEM user, WMI remote authentication will not work; this user has null credentials and Windows servers normally disallow such connections.

The following steps explain how to test the configuration of the Splunk server and the :

1. Log into the machine Splunk runs on as the user Splunk runs as.
2. Click Start -> Run and type wbemtest. The wbemtest application starts.
3. Click Connect and type \\<server>\root\cimv2, replacing <server> with the name of the remote server. Click Connect. If you are unable to connect, there is a problem with the authentication between the machines.
4. If you are able to connect, click Query and type select * from win32_service. Click Apply. After a short wait, you should see a list of running services. If this does not work, then the authentication works, but the user Splunk is running as does not have enough privileges to run that operation.

Configure WMI input

Look in $SPLUNK_HOME/etc/system/default/wmi.conf to see the default values for the WMI input. If you want to make changes to the default values, edit a copy of wmi.conf in $SPLUNK_HOME/etc/system/local/. You only have to provide values for the parameters you want to change for a given type of data input.

Refer to How configuration files work for more information about how Splunk uses configuration files, but be sure to use the new directory structure for the correct directory paths.

[settings]
initial_backoff = 5
max_backoff = 20
max_retries_at_max_backoff = 2
result_queue_size = 1000
checkpoint_sync_interval = 2
heartbeat_interval = 500

[WMI:AppAndSys]
server = foo, bar
interval = 10
event_log_file = Application, System, Directory Service
disabled = 0

[WMI:LocalSplunkWmiProcess]
interval = 5
wql = select * from Win32_PerfFormattedData_PerfProc_Process where Name = "splunk-wmi"
disabled = 0

The [settings] stanza specifies runtime parameters. The entire stanza and every parameter within it are optional. If the stanza is missing, Splunk assumes system defaults.

These parameters control how the agent reconnects to a given WMI provider when an error occurs. All times are in seconds:
- initial_backoff: how much time to wait the first time after an error occurs before trying to reconnect. Thereafter, if errors keep occurring, the wait time doubles, until it reaches max_backoff.
- max_backoff: the maximum amount of time to wait before invoking max_retries_at_max_backoff.
- max_retries_at_max_backoff : if the wait time reaches max_backoff, try this many times at this wait time. If the error continues to occur, Splunk will not reconnect to the WMI provider in question until the Splunk services are restarted.
result_queue_size: size of the queue that ensures that WMI providers don't end up blocking while waiting for data to be written to the output. Results received from the WMI providers are put into this queue.
checkpoint_sync_interval: minimum wait time for state data (event log checkpoint) to be written to disk. In seconds.
heartbeat_interval: the thread that manages the connection to WMI providers will execute at this interval. In milliseconds.

You can specify two types of data input: event log, and raw WQL (WMI query language) The event log input stanza contains the event_log_file parameter, and the WQL input stanza contains wql.

The common parameters for both types are:

server: a comma-separated list of servers from which to pull data. If this parameter is missing, Splunk assumes the local machine.
interval : how often to poll for new data, in seconds. Required.
disabled: indicates whether this feature is enabled or disabled. Set this parameter to 1 to disable WMI input into Splunk.

WQL-specific parameters:

namespace: specifies the path to the WMI provider. The local machine must be able to connect to the remote machine using delegated authentication. This parameter is optional. If you don't specify a path to a remote machine, Splunk will connect to the default local namespace (\root\cimv2), which is where most of the providers you are likely to query reside. Microsoft provides a list of namespaces for Windows XP and later versions of Windows.
wql: provides the WQL query. The example above polls data about a running process named splunkd every 5 seconds.

Event log-specific parameter:
event_log_file: specify a comma-separated list of log files to poll in the event_log_file parameter. File names that include spaces are supported, as shown in the example.

Source and source type for WMI data

All events are indexed in Splunk with a source of wmi.

For event log data, the source type is set to "WinEventLog:<name of log file>" (for example WinEventLog:Application).
For WQL data, the the source type is set to the name of the config stanza (for example, for a stanza named [WMI:LocalSplunkdProcess], the field is set to WMI:LocalSplunkProcess).

The host is identified automatically from the data received.

Previous: Configure inputs for Windows | Next: Windows registry input

Comments

No comments have been submitted.