Knowledge Management

What is replicated across Search Heads without CLI?

NightShark
Path Finder

I have recently created a field extraction on one search head that I have assigned all apps and users to read and write and was wondering how long is would take for a change done in one search head to get replicated to other search heads?

Also from what I know is that changes done via the GUI are always replicated to other SHs, is this true? If so what CAN and CANNOT be replicated across other search heads via gui.

Thanks,

Regards,

Labels (4)
0 Karma
1 Solution

Azeemering
Builder

These are the main types of configuration changes that the cluster replicates:

  • Runtime changes or additions to knowledge objects, such as saved searches, lookup table and dashboardss.
    For example, when a user in Splunk Web defines a field extraction, the cluster replicates that field extraction to all search heads in the cluster.
  • Runtime changes to users and roles.

Replication operates under these constraints:

  • The cluster only replicates changes made at runtime, through specific configuration methods.
  • A whitelist determines the specific types of changes that the cluster replicates.

Configuration methods that trigger replication

The cluster replicates changes made through these methods:

  • Splunk Web
  • The Splunk CLI
  • The REST API

The cluster does not replicate any configuration changes that you make manually, such as direct edits to configuration files.

 

The cluster uses a whitelist to determine what changes to replicate. This whitelist is configured through the set of conf_replication_include attributes in the default version of server.conf, located in $SPLUNK_HOME/etc/system/default.

You can add or remove items from that list by editing the members' server.conf files under $SPLUNK_HOME/etc/system/local. If you change the whitelist, you must make the same changes on all cluster members.

For a comprehensive list of items in the whitelist, consult the default version of server.conf. This is the approximate set of whitelisted items:

alert_actions 
authentication 
authorize 
datamodels 
event_renderers 
eventtypes 
fields 
html 
literals 
lookups 
macros 
manager 
models 
multikv 
nav 
panels 
passwd
passwords
props 
quickstart 
savedsearches 
searchbnf 
searchscripts 
segmenters 
tags 
times 
transforms 
transactiontypes 
ui-prefs 
user-prefs 
views 
viewstates 
workflow_actions

The cluster replicates changes to all files underlying the whitelist items. In addition to configuration files themselves, this includes dashboard and nav XML, lookup table files, data model JSON files, and so on. The cluster also replicates permissions stored in *.meta files.

These are examples of the types of files replicated for various whitelist items:

# escape-hatch HTML views
conf_replication_include.html = true
# lookup table files
conf_replication_include.lookups = true
# manager XML
conf_replication_include.manager = true
# datamodel JSON files
conf_replication_include.models  = true
# nav XML
conf_replication_include.nav = true
# view XML
conf_replication_include.views = true

Note: The cluster does not replicate user search history 

View solution in original post

NightShark
Path Finder

Thank you very much for the detailed explanation.

0 Karma

Azeemering
Builder

These are the main types of configuration changes that the cluster replicates:

  • Runtime changes or additions to knowledge objects, such as saved searches, lookup table and dashboardss.
    For example, when a user in Splunk Web defines a field extraction, the cluster replicates that field extraction to all search heads in the cluster.
  • Runtime changes to users and roles.

Replication operates under these constraints:

  • The cluster only replicates changes made at runtime, through specific configuration methods.
  • A whitelist determines the specific types of changes that the cluster replicates.

Configuration methods that trigger replication

The cluster replicates changes made through these methods:

  • Splunk Web
  • The Splunk CLI
  • The REST API

The cluster does not replicate any configuration changes that you make manually, such as direct edits to configuration files.

 

The cluster uses a whitelist to determine what changes to replicate. This whitelist is configured through the set of conf_replication_include attributes in the default version of server.conf, located in $SPLUNK_HOME/etc/system/default.

You can add or remove items from that list by editing the members' server.conf files under $SPLUNK_HOME/etc/system/local. If you change the whitelist, you must make the same changes on all cluster members.

For a comprehensive list of items in the whitelist, consult the default version of server.conf. This is the approximate set of whitelisted items:

alert_actions 
authentication 
authorize 
datamodels 
event_renderers 
eventtypes 
fields 
html 
literals 
lookups 
macros 
manager 
models 
multikv 
nav 
panels 
passwd
passwords
props 
quickstart 
savedsearches 
searchbnf 
searchscripts 
segmenters 
tags 
times 
transforms 
transactiontypes 
ui-prefs 
user-prefs 
views 
viewstates 
workflow_actions

The cluster replicates changes to all files underlying the whitelist items. In addition to configuration files themselves, this includes dashboard and nav XML, lookup table files, data model JSON files, and so on. The cluster also replicates permissions stored in *.meta files.

These are examples of the types of files replicated for various whitelist items:

# escape-hatch HTML views
conf_replication_include.html = true
# lookup table files
conf_replication_include.lookups = true
# manager XML
conf_replication_include.manager = true
# datamodel JSON files
conf_replication_include.models  = true
# nav XML
conf_replication_include.nav = true
# view XML
conf_replication_include.views = true

Note: The cluster does not replicate user search history 

PickleRick
SplunkTrust
SplunkTrust

Ehhh. "The cluster doesn't replicate user search history". It's true. It's also confusing because there is an option for it set by default to false but setting it to true doesn't do anything. 😆

0 Karma
Get Updates on the Splunk Community!

Continuing Innovation & New Integrations Unlock Full Stack Observability For Your ...

You’ve probably heard the latest about AppDynamics joining the Splunk Observability portfolio, deepening our ...

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...

Cloud Platform & Enterprise: Classic Dashboard Export Feature Deprecation

As of Splunk Cloud Platform 9.3.2408 and Splunk Enterprise 9.4, classic dashboard export features are now ...