Set the app context for standard mode federated providers
All Splunk searches run within the context of an app such as Search and Reporting. The app context determines the set of knowledge objects that the search head applies to the search during search processing. For example, when you run Splunk searches while you use the Search app, the app context of those searches guarantees that your search head applies Search-specific knowledge objects such as calculated fields, lookups, and field extractions to those searches.
The concept of app context is also crucial to searches that you run with Federated Search for Splunk. When you run a federated search over a remote Splunk platform deployment, you must ensure that the Splunk software applies the same app context to the local and remote portions of the search. However, when you run a federated search over a standard mode federated provider, there is no way for the provider's remote search head to detect the app context of the local search head.
Resolve this issue by identifying the app context of the standard mode federated provider when you define the provider: Set the federated provider's Application short name to the short name of the desired app. Install the app on the federated provider if it isn't currently installed there.
Later, when you run a federated search over a standard mode federated provider, make sure the provider has the same Application short name as the app context of the search. If there is an app context mismatch, your federated searches might fail or return incorrect results because they are using different sets of knowledge objects on the local and remote sides of the federated search.
Transparent mode federated providers do not require the Application short name field. In transparent mode, federated searches apply the application context that is active when the search is run on the local search head to the remote search heads on the federated providers.
For more information about federated provider setup, see Define a Splunk platform federated provider.
For help with app installation:
- If you use Splunk Cloud Platform, see Install apps on your Splunk Cloud Platform deployment in the Splunk Cloud Platform Admin Manual.
- If you use Splunk Enterprise, see Where to get more apps and add-ons in the Admin Manual.
Benefits of setting an app context
Setting an app context for a standard mode federated provider serves three purposes.
Purpose | Details |
---|---|
Knowledge object scoping | Provision of an app context ensures that federated searches that use the federated provider are limited to the knowledge objects that are associated with the named app. |
Provision of workload management limits | An app context allows administrators of the federated provider to set app-based workload management limits on your federated searches. |
Logging and auditing | The app context simplifies logging and auditing of the federated provider. |
Find installed apps and their application short names
To see which apps are installed on a specific Splunk platform deployment, in Splunk Web on that deployment, select Apps > Manage Apps to go to the Apps listing page. On the Apps listing page, the short names of the installed apps appear in the Folder name column.
Create 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 app context, federated searches, the portions of federated searches that run over that provider 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 app, it fails 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 app contexts. You can do this as long as each federated provider configuration has a unique name. For example, you can use the following three standard mode 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 provider names.
See Define a Splunk platform federated provider.
Duplicate knowledge objects on local and remote search heads
When you run federated searches that involve knowledge objects over standard mode federated providers, you must ensure that the same sets of knowledge objects are present on the local and remote search heads. If you do not do this, you risk having your searches fail or return incorrect results. See Custom knowledge object coordination for standard mode federated providers.
Service accounts and security for Federated Search for Splunk | Custom knowledge object coordination for standard mode federated providers |
This documentation applies to the following versions of Splunk Cloud Platform™: 9.1.2308, 9.1.2312, 9.2.2403, 9.2.2406 (latest FedRAMP release), 9.3.2408, 9.0.2305
Feedback submitted, thanks!