Splunk Cloud Platform

Search Manual

Acrobat logo Download manual as PDF


This documentation does not apply to the most recent version of SplunkCloud. Click here for the latest version.
Acrobat logo Download topic as PDF

Determine which knowledge objects are applied to federated searches

When you set up a federated provider, you need to 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 Set up a federated provider.

How knowledge object application works for single-deployment searches

When you run a 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

With federated searches, you need to make some advance decisions about the knowledge objects that are 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
Federated search involves multiple search heads across multiple Splunk platform deployments Each Splunk platform deployment has its own set of knowledge objects. The potential risk is that these different search heads might apply knowledge objects with the same type and name but different definitions to a single federated search, which produces inconsistent search results.

See Should your federated searches include local or remote knowledge objects?
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.
Remote search heads cannot detect application context of 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 that is installed on the federated provider. It defaults to the Search app.

The Application Short Name setting is valid only when the Local Knowledge Objects setting is disabled. If you are using local knowledge objects, you are using knowledge objects that have the application context of your local federated search head.

Should your federated searches use local or remote knowledge objects?

Because a federated search is spread across multiple Splunk platform deployments, it can potentially apply knowledge objects from all of those deployments to the search. This process can cause problems if you are not intimately aware of the knowledge object sets on each deployment included in your federated search.

For example, let's say you have a federated search that references a lookup configuration named http_status. You set up your search to return results from datasets on two federated providers, as well as your own local Splunk platform deployment. If each of the three Splunk platform deployments in your federated search has a lookup configuration named http_status, but each of those lookups references a different CSV lookup table, you might get a mismatched set of lookup fields applied to the results of your search if the Local Knowledge Objects setting on the Add Federated Provider page in Splunk Web is also disabled on those federated providers.

In most cases, it is best if your federated searches centralize their knowledge object pools. This is why, when you define federated providers in Splunk Web, the Local Knowledge Objects setting is enabled by default. The setting ensures that federated search processes on the federated provider use only knowledge objects from the federated search head. In other words, if the Local Knowledge Objects setting is enabled for all of the federated providers in your federated search, all of the remote search heads on those federated providers use knowledge objects from your local federated search head when they process the federated search.

When the remote Splunk deployment uses search head clustering

If possible, disable the Local Knowledge Objects setting for federated providers on remote Splunk deployments that use search head clustering. This is especially important if you have set up the load balancer as the federated provider for the search head cluster. As load balancers manage data traffic for their clusters, they can drop knowledge object bundles on different cluster nodes from the cluster nodes on which they run federated searches. This can cause your federated searches to fail.

If your remote deployment uses search head clustering and you must use local knowledge objects for your federated searches, set up each of the search heads in the search head cluster as federated providers, and turn Local Knowledge Objects on for each 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. 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, go to 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 federated providers that have the same host name but different app contexts

If a federated provider has the Search app as its application context, federated searches you run with it can use or reference only the lookups, aliases, search-time field extractions, and other knowledge objects that are associated with the Search app. If you run a federated search that references a lookup 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 federated provider definitions that use the same host 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-es buttercup.games.splunkcloud.com:8089 SplunkEnterpriseSecuritySuite
buttercupgames-itsi buttercup.games.splunkcloud.com:8089 itsi
Last modified on 11 August, 2021
PREVIOUS
Set up a federated provider service account
  NEXT
Define a federated provider

This documentation applies to the following versions of Splunk Cloud Platform: 8.2.2105 (latest FedRAMP release), 8.2.2106


Was this documentation topic helpful?

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters