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
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
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, 188.8.131.52:8089, 184.108.40.206:8089, 220.127.116.11: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 = 18.104.22.168:8089, 22.214.171.124:8089, 126.96.36.199:8089
Note the following:
serversattribute 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
- 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
defaultattribute 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.
Manage distributed server names
Remove a search peer
This documentation applies to the following versions of Splunk® Enterprise: 6.5.0, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 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.2.0, 8.2.1, 8.2.2, 8.2.3