Splunk Cloud Platform

Search Manual

Acrobat logo Download manual as PDF


Acrobat logo Download topic as PDF

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-es buttercup.games.splunkcloud.com:8089 SplunkEnterpriseSecuritySuite
buttercupgames-itsi buttercup.games.splunkcloud.com:8089 itsi

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.

Last modified on 30 November, 2021
PREVIOUS
Service accounts and federated search security
  NEXT
Define a federated provider

This documentation applies to the following versions of Splunk Cloud Platform: 8.2.2109, 8.2.2111


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