Distributed Search and Forwarder Management
Distributed search
A search head fans searches out to indexers listed in distsearch.conf ([distributedSearch] servers), or added with splunk add search-server -auth <user>:<pass> https://<indexer>:8089. The search head must have the same search-time knowledge (props/transforms, lookups, field extractions) as the indexers; missing knowledge objects are the classic reason a search returns nothing in a distributed deployment. Search head cluster members share a pass4SymmKey, elect a captain, and receive configuration from a deployer.
Forwarder management
The deployment server distributes configuration to forwarders. Clients point at it via deploymentclient.conf [target-broker:deploymentServer] targetUri. On the server, serverclass.conf defines server classes with client filters (whitelist/blacklist) and the apps to push from $SPLUNK_HOME/etc/deployment-apps. Clients poll on phoneHomeIntervalInSecs.
Traps
- Using the deployment server for indexer cluster configuration - peers take that from the cluster manager.
- Placing apps in
etc/appson the deployment server instead ofdeployment-apps. - A client matching multiple server classes, where ordering decides the result.
- Pushing heavy search-time knowledge to forwarders, or parsing config to search heads only.
Rule of thumb
Deploy the minimum: inputs, outputs, and forwarder-side parsing only. Verify with splunk list deploy-clients on the server and the client's effective deploymentclient.conf.