Splunk® Enterprise

Distributed Search

Splunk Enterprise version 9.0 will no longer be supported as of June 14, 2024. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.

Create distributed search groups

You can group your search peers to facilitate searching on a subset of them. Groups of search peers are known as "distributed search groups." You specify distributed search groups in the distsearch.conf file.

For example, say you have a set of search peers in New York and another set in San Francisco, and you want to perform searches across peers in just a single location. You can do this by creating two search groups, NYC and SF. You can then specify the search groups in searches.

Distributed search groups are particularly useful when configuring the monitoring console. See Monitoring Splunk Enterprise.

Configure distributed search groups

You define distributed search groups in distsearch.conf.

For example, to create the two search groups NYC and SF, create stanzas like these:

[distributedSearch]
# This stanza lists the full set of search peers.
servers = 192.168.1.1:8089, 192.168.1.2:8089, 175.143.1.1:8089, 175.143.1.2:8089, 175.143.1.3:8089

[distributedSearch:NYC]
# This stanza lists the set of search peers in New York.
default = false
servers = 192.168.1.1:8089, 192.168.1.2:8089

[distributedSearch:SF]
# This stanza lists the set of search peers in San Francisco.
default = false
servers = 175.143.1.1:8089, 175.143.1.2:8089, 175.143.1.3:8089

Note the following:

  • The servers attribute lists groups of search peers by IP address and management port.
  • The servers list for each search group must be a subset of the list in the general [distributedSearch] stanza.
  • The group lists can overlap. For example, you can add a third group named "Primary_Indexers" that contains some peers from each location.
  • If you set a group's default attribute to "true," the peers in that group will be the ones queried when the search does not specify a search group. Otherwise, if you set all groups to "false," the full set of search peers in the [distributedSearch] stanza will be queried when the search does not specify a search group.

Use distributed search groups

To use a search group in a search, specify the search group like this:

sourcetype=access_combined status=200 action=purchase splunk_server_group=NYC | stats count by product

This search runs against only the peers in the NYC location.

Distributed search groups and indexer clusters

This feature is not valid for indexer clustering, except for limited use cases in certain complex topologies.

In indexer clustering, the cluster replicates the data buckets arbitrarily across the set of search peers, or "cluster peer nodes". It then assigns one copy of each bucket to be the primary copy, which participates in searches. There is no guarantee that a specific peer or subset of peers will contain the primary bucket copies for a particular search. Therefore, if you put peers into distributed search groups and then run searches based on those groups, the searches might contain incomplete results.

For details of bucket replication in indexer clusters, see Buckets and indexer clusters in Managing Indexers and Clusters of Indexers.

These are some examples of indexer cluster deployments where distributed search groups might be of value:

  • Multiple indexer clusters, where you need to identify the peer nodes for a specific cluster.
  • Search heads that run searches across both an indexer cluster and standalone indexers. You might want to put the standalone indexers into their own group.
Last modified on 13 February, 2017
Manage distributed server names   Remove a search peer

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters