Admin Manual

 


App architecture and object ownership

NOTE - Splunk version 4.x reached its End of Life on October 1, 2013. Please see the migration information.

This documentation does not apply to the most recent version of Splunk. Click here for the latest version.

App architecture and object ownership

Apps and add-ons are commonly built from Splunk knowledge objects. Splunk knowledge objects includes saved searches, event types, tags -- data types that enrich your Splunk deployment and make it easier to find what you need.

Any user logged into Splunk Web can create and save knowledge objects to the user's directory under the app the user's "in" (assuming sufficient permissions). This is the default behavior -- whenever a user saves an object, it goes into the user's directory in the currently running app. The user directory is located at $SPLUNK_HOME/etc/users/<user_name>/<app_name>/local. Once the user has saved the object in that app, it is available only to that user when they are in that app, unless they do one of the following:

  • 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 the app's context)
  • Mark the object as globally available to all apps and users (unless you've explicitly restricted it by role/user)

Note: Users must have write permissions for an app before they can promote objects to the app level.

Promote and share Splunk knowledge

Users can 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 created. So if you create a saved search in the app "Fflanda" and share it, other users of Fflanda can see your saved search if they have read permission for Fflanda.

Users with write permission can promote their objects to the app level. This means the objects are copied from their user directory to the app's directory -- from:

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

to:

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

Users can do this only 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 make globally available an object "A" (defined in "B.conf") that belongs to user "C" in app "D":

1. Move the stanza defining the object A from $SPLUNK_HOME/etc/users/C/D/B.conf into $SPLUNK_HOME/etc/apps/D/local/B.conf.

2. Add a setting, export = system, to the object A's stanza in 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:

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

2. 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 knowledge objects discussed here are limited to those that are subject to access control. These objects are 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. These objects include:

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

There are also system-level objects available only to users with admin privileges (or read/write permissions on the specific objects). These are also managed through Splunk Manager. These objects include:

  • 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 the copy of inputs.conf that belongs to the app you're currently in. This means that if you navigated to Splunk Manager directly from Search, your input will be added to $SPLUNK_HOME/etc/apps/search/local/inputs.conf, which might not be the behavior you desire.

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 Splunk configuration files and the order of precedence.

This documentation applies to the following versions of Splunk: 4.1 , 4.1.1 , 4.1.2 , 4.1.3 , 4.1.4 , 4.1.5 , 4.1.6 , 4.1.7 , 4.1.8 , 4.2 , 4.2.1 , 4.2.2 , 4.2.3 , 4.2.4 , 4.2.5 , 4.3 , 4.3.1 , 4.3.2 , 4.3.3 , 4.3.4 , 4.3.5 , 4.3.6 , 4.3.7 , 5.0 , 5.0.1 , 5.0.2 , 5.0.3 , 5.0.4 , 5.0.5 , 5.0.6 , 5.0.7 , 5.0.8 View the Article History for its revisions.


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

Was this documentation topic helpful?

If you'd like to hear back from us, please provide your email address:

We'd love to hear what you think about this topic or the documentation as a whole. Feedback you enter here will be delivered to the documentation team.

Feedback submitted, thanks!