CARVIEW |
Distributed Search
- System requirements and other deployment considerations for search head clusters
- Deploy a search head cluster
- Integrate the search head cluster with an indexer cluster
- Connect the search heads in clusters to search peers
- Add users to the search head cluster
- Use a load balancer with search head clustering
- Deploy a search head cluster in a multisite environment
- Deploy a single-member search head cluster
- Migrate settings from a standalone search head to a search head cluster
- Migrate from a search head pool to a search head cluster
- Upgrade a search head cluster
- Perform a rolling upgrade of a search head cluster
- Perform an automated rolling upgrade of a search head cluster
- Add a cluster member
- Remove a cluster member
- Configure a cluster member to run ad hoc searches only
- Control search concurrency on search head clusters
- Control captaincy
- Handle failure of a search head cluster member
- Use static captain to recover from loss of majority
- Put a search head cluster member into detention
- Restart the search head cluster
- Back up and restore search head cluster settings
- How to best debug splunk scheduler issues for Splu...
- Splunk S3 Generic Input not fetching objects in bu...
- Why is the website monitoring app giving the error...
- Splunk 7.3.1, Windows 10 - "AfterGlow was not able...
- timestamp extraction issue
- Email ingestion from O365: Different artifacts gen...
- SSL Issue in testing LOCAL Splunk : [SSL: CERTIFIC...
- Correlation Search generated by Multi-KPI Alert is...
- KV Store - Is it one per Search Head Cluster or on...
- CORS POLICY ISSUE : Unable to call REST API using ...
General troubleshooting issues
Clock skew between search heads and search peers can affect search behavior
You must keep the clocks on your search heads and search peers in sync, via NTP (network time protocol) or some similar means. The nodes require close clock alignment, so that time comparisons are valid across systems. If the clocks are out-of-sync by more than a few seconds, distributed search cannot work correctly, resulting in search failures or premature expiration of search artifacts.
When you add a search peer to a search head, the search head checks that the clocks are in sync. This check ensures that the system time, independent of the timezone, agrees across the nodes of a distributed search environment. If the nodes are out of sync, the search head rejects the search peer and displays a banner message like this:
The time difference between this system and the intended peer at uri=https://servername:8089/ was too big. Please bring the system clocks into agreement.
Note: The search head does not run this check if you add the search peer by direct edit of distseach.conf
.
Searches can fail if configurations in a knowledge bundle have not yet been replicated to search peers
Configuration changes can take a short time to propagate from search heads to search peers. As a result, during the time between when configuration changes are made on the search head and when they're replicated to the search peers (typically, not more than a few minutes), distributed searches can either fail or provide results based on the previous configuration.
Types of configuration changes that can cause search failures are those that involve new apps or changes to authentication.conf
or authorize.conf
. Examples include:
- changing the allowed indexes for a role and then running a search as a user within that role
- creating a new app and then running a search from within that app
Any failures will be noted in messages on the search head.
Types of changes that can provide results based on the previous configuration include changing a field extraction or a lookup table file.
To remediate, run the search again.
Network problems can reduce search performance
A 6.0 or later search head by default asks its search peers to generate a remote timeline. This can result in slow searches if the connection between the search head and the search peers is unstable.
The workaround is to add the following setting to limits.conf
on the search head :
[search] remote_timeline_fetchall = false
After making this change, you must restart the search head.
Use the monitoring console to view distributed search status | Handle slow search peers |
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.1.8, 9.1.9, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.2.5, 9.2.6, 9.3.0, 9.3.1, 9.3.2, 9.3.3, 9.3.4, 9.4.0, 9.4.1, 9.4.2
Comments
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.
Your Comment Has Been Posted Above
Feedback submitted, thanks!