Determine which knowledge objects are applied to federated searches

When you set up a standard mode federated provider, you must consider where federated searches that are run on that provider will get their knowledge objects. You do this on the Add Federated Provider page in Splunk Web by setting the Application Short Name setting for the provider and by using the Local Knowledge Objects setting to determine whether the provider uses local or remote knowledge objects.

This topic explains the significance of these settings.

To learn how to set these settings when you define a federated provider, see Define a federated provider.

How knowledge object application works for single-deployment searches

When you run a normal search on a single Splunk platform deployment, the search process automatically applies sets of knowledge objects such as field extractions, lookups, tags, and event types to searches.

When you run an ordinary search over data in a single Splunk platform deployment, you do not need to think much about the knowledge object sets your search head applies to your searches. This is because the search head on your Splunk platform deployment uses your application context to determine which knowledge objects to apply. Your application context is defined by the app you are using when you run the search.

For example, if you run a search while you are using the Search app, your search head applies the knowledge objects that belong to the Search app to your search. If you switch to the Enterprise Security app and run another search, your search head applies the knowledge objects that belong to the Enterprise Security app to that search.

Why federated search is different

When you set up standard mode federated providers, you must consider the knowledge objects that will be used in your searches. The following table lists two situations with knowledge objects in federated searches, explains those situations, and names the settings that address those situations.

Situation	Explanation	Solution
Remote search heads cannot detect the application context of the local federated search head	When parts of your federated search take place on the remote search heads of federated providers, and you are not using local knowledge objects, the remote search heads must have an application context for the search. The application context helps them apply the correct set of knowledge objects to their portion of the search. Setting an application short name also helps with workload management limit provision and with logging and auditing. See Set the application context for your federated provider.	On the Add Federated Provider page in Splunk Web, set the Application Short Name setting for the federated provider to the short name of an app. Application Short Name defaults to the Search and Reporting app.
Federated search involves multiple search heads across multiple Splunk platform deployments	Each Splunk platform deployment has its own set of knowledge objects. If you will use knowledge objects from the federated search head and one or more remote search heads in a single federated search, verify that the search heads won't apply knowledge objects with the same type and name but different definitions to the search, as this might produce inconsistent search results.	On the Add Federated Provider page in Splunk Web, enable the Local Knowledge Objects setting for the federated provider. When enabled, this setting ensures that federated searches on the federated provider use only knowledge objects from the local federated search head. Local Knowledge Objects cannot be disabled for transparent mode federated providers.

When your federated provider has Local Knowledge Objects enabled, you also must give its service account role the fsh_manage capability, which in turn grants the admin of the federated search head on the local Splunk deployment the ability to authorize access to data on the federated provider.

See Service accounts and federated search security.

When the remote Splunk deployment uses search head clustering

If your remote Splunk deployment uses search head clustering, you can set up the cluster's load balancer to act as the federated provider for the deployment, so that the load balancer can manage the distribution of federated search data to and from the members of the search head cluster.

This "load balancer as federated provider" approach works for standard mode federated search, as long as you disable the Local Knowledge Objects setting for the provider. As a load balancer manages data traffic for its search head cluster, it can drop replicated knowledge object bundles on different cluster members from the cluster members on which it runs federated searches. This knowledge object misplacement can cause your federated searches to fail.

You cannot set up a load balancer as a transparent mode federated provider.

Set the application context for your federated provider

The Application Short Name setting provides an application context for the searches you run against remote datasets on the federated provider. Application Short Name defaults to the Search and Reporting app.

When you run a federated search with the federated provider, the federated search always applies the application context set by Application Short Name to the portion of the search that takes place on the federated provider. Application Short Name overrides the application context set by the federated search head on your local Splunk platform deployment.

For example, let's say that when you run searches solely on your local Splunk platform deployment, they run with the Search and Reporting app context. If you instead run a federated search from your local deployment over a federated provider that has Application Short Name set to AppXYZ, the portion of the federated search that runs on that federated provider uses AppXYZ as its application context instead of Search and Reporting.

How you set Application Short Name for a federated provider depends on whether Local Knowledge Objects is enabled or disabled for that provider.

Local Knowledge Objects setting	How to set Application Short Name
Disabled	Provide the short name of an app that exists on the remote search head of the federated provider.
Enabled	Provide the short name of an app that exists on both the remote search head of the federated provider and the federated search head of your local Splunk platform deployment.

Setting an application context for a federated provider serves three purposes.

Purpose	Details
Knowledge object scoping	Provision of an application context ensures that federated searches that use the federated provider are limited to the knowledge objects that are associated with the named application.
Provision of workload management limits	The application context allows administrators of the federated provider to set app-based workload management limits on your federated searches.
Logging and auditing	The application context simplifies logging and auditing of the federated provider.

Finding installed apps and their application short names

To find what applications are installed on a specific Splunk platform deployment, in Splunk Web on that deployment, select Apps > Manage Apps. This takes you to the Apps listing page, where the short names of the installed apps are provided in the Folder name column.

Creating standard mode federated providers that have the same host name but different app contexts

If a standard mode federated provider has the Search app as its application context, federated searches you run with it can use or reference only the tags, aliases, search-time field extractions, and other knowledge objects that are associated with the Search app. If you run a federated search that references an alias or calculated field that is associated with another application, such as Splunk Enterprise Security or Splunk IT Service Intelligence, it will fail on the federated provider because it can't find those knowledge objects in the Search app.

Remedy this problem by creating multiple standard mode federated provider definitions that use the same host and port but which have different application contexts. You can do this as long as each federated provider configuration has a unique name. For example, you can use the following three federated provider configurations concurrently even though they all search data on the same remote host:

Federated provider name	Remote host	Application short name
buttercupgames-search	buttercup.games.splunkcloud.com:8089	search
buttercupgames-custom1	buttercup.games.splunkcloud.com:8089	your_custom_app1
buttercupgames-custom2	buttercup.games.splunkcloud.com:8089	your_custom_app2

You can set up multiple standard mode providers with the same host and port as long as they have different names. Local Knowledge Objects is enabled for two or more federated providers with the same host name and port, the knowledge objects are only replicated once, meaning you will not end up with multiple bundle replications of knowledge object sets for a single host name and port.

See Define a federated provider.