Community:Considerations for deciding how to get data from Windows hosts

From Splunk Wiki

Jump to: navigation, search

Considerations for deciding how to get data from Windows hosts

The best way to get data off of a Windows host is with local Splunk forwarder. Using a local forwarder offers the most types of data sources, minimizes network overhead and reduces operational risk and complexity.

However, there are circumstances – from organizational boundaries to local performance considerations – where remote collection is preferred. For these situations Splunk supports using the native WMI interface on Windows to collect Event Logs and performance data.

This table offers a list of data sources, and trade-offs, for you to consider.

Data Source Considerations
Data Source Local Forwarder Remote Polling
Event Logs Yes Yes*
Performance Yes Yes
Registry Yes No
Log Files Yes Yes**
Crawl Yes No

* Note that for remote Event Log collection, you *must* know the name of the Event Log you wish to collect. On local forwarders, you have the option to collect all logs, regardless of name

**Note that remote log file collection using {\\servername\share\} syntax is supported, however you must use CIFS as your application layer file access protocol and Splunk must have at least read access to both the share and the underlying file system


Tradeoffs:

Performance.

For identical collecting local Event Logs and flat log files, a local forwarder requires less CPU and performs basic pre-compression of the data; it is more memory intensive, mostly owing to the additional data source input options. WMI remote polling is more CPU intensive on the target for the same set of data (either remote Event Logs or remote performance data) and more network intensive.

Note that for highly audited hosts, such as domain controllers, remote polling may not be able to keep up with the volume of data or Event Log events. Remote polling is best-effort by design of the WMI API, and is throttled to prevent unintentional denial of service attacks.

Deployment.

Local forwarders are easier where you have control of the base OS build, and/or if you have many data sources, especially if transformation of data is required. Remote polling works well when you want a limited set of data from a large number of hosts (for example, just process CPU data for usage billing). Remote polling may be your only option where you don’t have either build control or local administrator privileges on the target host.

A common usage scenario is to first test using remote polling, then add successful or useful polls to your local forwarding configuration later, or at mass deployment time.

Management.

Both mechanisms offer logging and, potentially, alerting to let you know if a host is coming on or offline or is no longer connected. However, to prevent an unintentional denial of service attack the WMI polling service in Splunk will start to poll less frequently over time if it is unable to contact a host for a period of time. Therefore remote polling is not advised for machines that are frequently offline, such as laptops or dynamically provisioned virtual machines.

Personal tools
Hot Wiki Topics


About Splunk >
  • Search and navigate IT data from applications, servers and network devices in real-time.
  • Download Splunk