Splunk Search

Large Knowledge Bundle replication

pcsegal
Explorer

Hi,

Background: I have a standalone Splunk Enterprise environment. It has "Geospatial" lookup definitions pointing to KML lookup files, and many searches depend on these geospatial lookups. There are currently 24 such lookups (and the number can potentially grow) for several countries; that is, several hundred megabytes worth of lookup files. I need to migrate this to a clustered environment with one master, an indexer cluster (composed of 3 peers), and one search head.

I'm testing this in a development environment and am planning to move it to production, but I'm concerned about several details on how knowledge bundle replication works.

  1. Should I be concerned that I have a large set of geospatial lookup files?

  2. These geospatial lookup files will rarely, if ever, change. Only more may be added. Does this mean that their replication will only happen once they're added?

  3. I have read that you can blacklist lookup files from the knowledge bundle and use "local=true" in the searches, so that the lookups remain in the search head and are never replicated to the indexers. However, is it a good approach in terms of search performance?

Thank you in advance.

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

(re)Introducing the Splunk Community Champions + 2026 – 2027 Splunk MVPs ...

This program exists as a channel to empower and recognize Splunk advocates and help supercharge initiatives to ...

Introducing the 2026 - 2027 SplunkTrust cohort!

The goal of the SplunkTrust™ membership has historically been to acknowledge and recognize those who go above ...

Pro Tips for .conf26: How to Prep Like a Splunk Veteran

There’s no shortage of incredible content lined up for .conf26 in Denver, from deep-dive technical sessions ...