Manage configurations on a peer-by-peer basis
Most configurations need to be the same across all peers. See Manage common configurations across all peers. For limited purposes, such as testing, you can handle some configurations on a peer-by-peer basis.
Configure data inputs
Forwarders are the recommended way to handle data inputs to peers. For information on configuring this process, read Use forwarders to get your data into the indexer cluster.
If you want to input data directly to a peer, without a forwarder, you can configure your inputs on the peer in the same way as for any indexer. For more information, read Configure your inputs in the Getting Data In manual.
Important: Although you can configure inputs on a peer-by-peer basis, consider whether your needs allow you to use a single set of inputs across all peers. This should be possible if all data is channeled through forwarders, and the receiving ports on all peers are the same. If that is the case, you can use the master node to manage a common
inputs.conf file, as described in Update common peer configurations and apps.
Add an index to a single peer
If you need to add an index to a single peer, you can do so by creating a separate
indexes.conf file on the peer. However, the data in the new index will remain only on that peer and will not get replicated. The main use case for this is to perform some sort of local testing or monitoring, possibly involving an app that you download to only that one peer. The peer-specific
indexes.conf supplements, but does not replace, the common versions of the file that all peers get.
If you create a version of
indexes.conf for a single peer, you can put it in any of the acceptable locations for an indexer, as discussed in About configuration files and Configuration file directories in the Admin Manual. The one place where you cannot put the file is under
$SPLUNK_HOME/etc/slave-apps, which is where the configuration bundle resides on the peer. If you put it there, it will get overwritten the next time the peer downloads a configuration bundle.
Important: If you add a local index, leave its
repFactor attribute set to the default value of 0. Do not set it to
auto. If you do set it to
auto, the peer will attempt to replicate the index's data to other peers in the cluster. Since the other peers will not be configured for the new index, there will be nowhere on those peers to store the replicated data, resulting in various, potentially serious, problems. In addition, when the master next attempts to push a configuration bundle to the peers, the peer with the incorrectly configured index will return a bundle validation error to the master, preventing the master from successfully applying the bundle to the set of peers.
Make other configuration changes
If you need to make some other configuration changes specific to an individual peer, you can configure the peer in the usual way for any Splunk Enterprise instance, clustered or not. You can use Splunk Web or the CLI, or you can directly edit configuration files.
Restart the peer
As with any indexer, you sometimes need to restart a peer after you change its configuration. Unlike non-clustered indexers, however, do not use the CLI
splunk restart command to restart the peer. Instead, use the restart capability in Splunk Web. For detailed information on how to restart a cluster peer, read Restart a single peer.
For information on configuration changes that require a restart, see Restart after modifying server.conf? and Restart or reload after configuration bundle changes?.
Update common peer configurations and apps
Search head configuration overview
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 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.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, 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.1.0, 7.1.1, 7.1.2, 7.1.3, 7.2.0