App architecture and object ownership

App architecture and object ownership

Apps and add-ons are commonly built out of Splunk knowledge. Splunk knowledge is things like saved searches, event types, tags--items that enrich your Splunk data and make it easier to find what you need. In Splunk, these knowledge items are also known as objects.

Any user logged into Splunk Web can create and save these objects to his/her user directory under the app he or she is "in" (assuming they have sufficient permissions). This is the default behavior--any time any user saves an object, it goes into that user's directory for that app. The user directory is located at: $SPLUNK_HOME/etc/users/<user_name>/<app_name>/local. Once the user has saved the object for that app, it is available to that user only when they are in that app, unless they do one of the following things (and have the correct permissions to do so):

• Promote the object so that it is available to all users who have access to that app
• Restrict the object to specific roles or users (still within that app's context)
• Mark the object globally available to all apps (and users) (unless you've explicitly restricted it by role/user)

Promote and share Splunk knowledge

Users can then share their Splunk knowledge objects with other users through the Permissions dialog. This means users who have read permissions in an app can see the shared objects and use them. For example, if a user shares a saved search, other users can see that saved search, but only within the app in which the search was originally created. So if you create a saved search in app Fflanda, then share it, other users of app Fflanda can see your saved search if they have read permissions for app Fflanda as well.

Some users can have permissions to promote their objects to the app level. This means the objects are actually copied from their user directory to that app's directory:

from:

$SPLUNK_HOME/etc/users/<user_name>/<App_name>/local/

to:

$SPLUNK_HOME/etc/apps/<App_name>/local/

Users can only do this if they have write permission in the app.

Make Splunk knowledge objects globally available

Finally, upon promotion, users can decide if they want their object to be available globally, meaning all apps are able to see it. Again, the user must have permission to write to the original app. It's easiest to do this from within Manager, but you can also do it later by moving the relevant object into the desired directory.

To move an object A in B.conf from user C in app D:

Move the stanza defining A from B.conf in

$SPLUNK_HOME/etc/users/C/D/B.conf

to

$SPLUNK_HOME/etc/apps/D/local/B.conf

and then add an export = system setting under that object's stanza to the app's local.meta file. If the stanza for that object doesn't already exist, you can just add one.

For example, to promote an event type called rhallen created by a user named fflanda in the *Nix app so that it is globally available:

Move the [rhallen] stanza from $SPLUNK_HOME/etc/users/fflanda/unix/local/eventtypes.conf

to

$SPLUNK_HOME/etc/apps/unix/local/eventtypes.conf

and then add the following stanza:

[eventtypes/rhallen]
export = system

to $SPLUNK_HOME/etc/apps/unix/metadata/local.meta.

Note: Adding the export = system setting to local.meta isn't necessary when you're sharing event types from the Search app because it exports all of its events globally by default.

What objects does this apply to?

The objects discussed here are limited to those that are subject to access control. These objects also known as app-level objects and can be set in the App Configuration tab of Splunk Manager. This page is available to all users to manage any objects they have created and shared.

Includes:

• Saved searches and Reports
• Event types
• Views and dashboards
• Field extractions

Objects that are at the system level are managed through Manager and are only available to users with admin privileges (or those with permissions to read/write to the objects shown there).

Includes:

• Users
• Roles
• Auth
• Distributed search
• Inputs
• Outputs
• Deployment
• License
• Server settings (for example: host name, port, etc)

Important: If you add an input, Splunk adds that input to a copy of inputs.conf that belongs to the app you're in when you add that input. This means that if you navigated to Splunk Manager, directly from the launcher your input will be added to $SPLUNK_HOME/etc/apps/launcher/local/inputs.conf.

App configuration and knowledge precedence

When you add knowledge to Splunk, it's added in the context of the app you're in when you add it. When Splunk is evaluating configurations and knowledge, it evaluates them in a specific order of precedence, so that you can control what knowledge definitions and configurations are used in what context. Refer to About configuration files for more information about the configuration files Splunk uses and the order of precedence.