Deployment Architecture

Savedsearches in search app migrating to SHC

d_lim
Path Finder

Regarding the migration of knowledge objects from a standalone searchhead 'search' app to searchhead clustering environment, the docs recommends -

Migrate_settings_to_a_search_head_cluster 
Copy the .../search/local directory in the temporary directory to a new app directory, such as search_migration_app, in the temporary directory. Do not name this new app "search."

Following which after pushing from the deployer, should the knowledge objects be moved back to the search app via the search head??

The concern is that users will be using the 'search' and 'search_migration_app' and have to look through the 'search' and 'search_migration_app' for the objects.

Should the knowledge objects remain in the 'search_migration_app' and new objects to be saved into 'search' app?

Is there a way to bulk move the objects easily from the 'search_migration_app' to 'search' app?

Labels (3)
0 Karma

thambisetty
SplunkTrust
SplunkTrust
  1. you need to identify custom apps that you would like to move from standard alone search head to search head cluster. once you identify them, you need to place all identified custom apps under $SPLUNK_HOME/etc/shcluster/apps in your deployer 
  2. Since most of the splunk users use splunk search app most of the saved searches have been creating in search app under local directory.  you need to create new app "search_migration_app" under $SPLUNK_HOME/etc/shcluster/apps in your deployer. move local and lookups folders from search app to search_migration_app. create metadata folder under search_migration_app and create local.meta and add below content to local.meta:

 

[]
export = system

 

  •  you need to look at user profiles under $SPLUNK_HOME/etc/users because they might have created Knowledge objects and they might not be shared with others.
  • you should migrate lookups which are kept private to users carefully. if you directly copy user profile under $SPLUNK_HOME/etc/shcluster/users in deployer then the lookup files in apps will be appended with .default. for example user lookup is abcd.csv you will see lookup name abcd.csv.default and this will not be searchable in search head cluster. crate a app for user lookups and create lookups directory under app created move all users lookups under lookukps. create local.meta under metadata folder ( needs to be created as well) add above content.
  • Check if you have any lookups blacklisted in your distsearch.conf. path might be changed in search head cluster for blacklisting lookups.
  • check if you have any modular inputs/scripted inputs configured on search head for colleting data. if you move modular inputs TAs to search head cluster you might end up getting duplicate data from your search members because modular inputs and scripted inputs are not aware of search head cluster.

Coming to your questions:

Following which after pushing from the deployer, should the knowledge objects be moved back to the search app via the search head??

Not required. they can be part of new app deployed.  you need to give user access to new app deployed.

The concern is that users will be using the 'search' and 'search_migration_app' and have to look through the 'search' and 'search_migration_app' for the objects.

Yes, you are right.

Should the knowledge objects remain in the 'search_migration_app' and new objects to be saved into 'search' app?

Is there a way to bulk move the objects easily from the 'search_migration_app' to 'search' app?

I tried deploying search app from deployer but I didn't find the knowledge objects deployed to search members because I think search app is expected to be local not expected from deployer. That's when I had to create new app to deploy knowledge objects of search application to search members.

————————————
If this helps, give a like below.
Get Updates on the Splunk Community!

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...

New in Observability Cloud - Explicit Bucket Histograms

Splunk introduces native support for histograms as a metric data type within Observability Cloud with Explicit ...