How distributed search works
This documentation does not apply to the most recent version of Splunk.
This documentation applies to the following versions of Splunk: 3.0 , 3.0.1 , 3.0.2 , 3.1 , 3.1.1 , 3.1.2 , 3.1.3 , 3.1.4
Contents
How distributed search works
You can configure Splunk servers to distribute searches across other Splunk servers and merge the results. Distributed search is a peer-to-peer configuration. At login, authentication attempts will be federated across all other servers. Users will only be able to search those Splunk servers where their credentials are accepted. Users can restrict any search to explicitly search only a subset of the servers.
All Splunk servers in a distributed search configuration must have Enterprise licenses.
Distributed search is typically used:
- To enable correlation among multiple separate logical silos of data for a subset of users with greater privilege
- To provide a single view of data that has been distributed across multiple indexing servers for clustered scaling
- To provide a single view across Splunk servers that are indexing data locally on production hosts, where network bandwidth favors centralizing data at search time rather than index time
Note: Because distributed search uses the management port (default 8089), you must configure SSL either off or on for all servers. The default is to enable SSL on the management port. If you turn it off for one server, you must turn it off for all servers.
Known issues with distributed search
Currently, event types and saved searches are not federated across distributed search servers. As a result, if you are searching for eventtype::foo or savedsearch::bar, server1 will return anything that matches the search. Any other server in the distributed search will not return unless eventtype::foo or savedsearch::bar are also defined on those servers.