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 manager 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 manager node 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 manager, preventing the manager 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: 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
Feedback submitted, thanks!