Deployment Architecture

Should I be worried about these bundle replication messages??

ben_leung
Builder

Splunk Version 6.3.4
Search head cluster of 3 nodes
Indexer distributed search peers 4 nodes

I see the following error messages in _internal:

WARN DistBundleRestHandler - There was a problem renaming: /opt/splunk/var/run/searchpeers/F7521905-DA3E-4B9B-B2FE-08B911826B00-1465250902.b469fbba316fbf76.tmp -> /opt/splunkp/splunk/var/run/searchpeers/F7521905-DA3E-4B9B-B2FE-08B911826B00-1465250902: File exists 

ERROR DistBundleRestHandler - Problem untarring file: /opt/splunk/var/run/searchpeers/F7521905-DA3E-4B9B-B2FE-08B911826B00-1465250902.bundle 

WARN DistributedBundleReplicationManager - Asynchronous bundle replication to 4 peer(s) succeeded; however it took too long (longer than 10 seconds): elapsed_ms=48188, tar_elapsed_ms=10311, bundle_file_size=344190KB, replication_id=1465250902, replication_reason="async replication allowed"
0 Karma

woodcock
Esteemed Legend

Yes, as your search load increases, the bundle size will too and that will be compounded by the higher workload, too. Eventually the bundle replications will timeout and fail completely and the searches that go with them will fail. For this reason, many people setup cron jobs to delete ANY file that is more than x (typically 7) days old in the dispatch directory. Many times old files from long-ago-useless |outputcsv commands can accumulate causing this problem.

0 Karma

ben_leung
Builder

alt text

0 Karma
Get Updates on the Splunk Community!

Welcome to the Splunk Community!

(view in My Videos) We're so glad you're here! The Splunk Community is place to connect, learn, give back, and ...

Tech Talk | Elevating Digital Service Excellence: The Synergy of Splunk RUM & APM

Elevating Digital Service Excellence: The Synergy of Real User Monitoring and Application Performance ...

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...