Splunk® Enterprise

Knowledge Manager Manual

Download manual as PDF

Splunk Enterprise version 5.0 reached its End of Life on December 1, 2017. Please see the migration information.
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Download topic as PDF

Disable or delete knowledge objects

Let's start off by saying that Manager makes it fairly easy to disable or delete knowledge objects as long as your permissions enable you to do so. In Splunk, the ability to delete knowledge objects in Manager really depends on a set of factors:

  • You cannot delete default knowledge objects that were delivered with Splunk (or with the App) via Manager. If the knowledge object definition resides in the app's default directory, it can't be removed via Manager. It can only be disabled (by clicking Disable). Only objects that exist in an app's "local" directory are eligible for deletion.
  • You can delete knowledge objects that you have created, and which haven't been shared. Once a knowledge object you've created is shared with other users, your ability to delete it is revoked, unless you have write permissions for the app to which they belong (see the next point).
  • To delete all other knowledge objects, you need to have write permissions for the app to which they belong. This applies to knowledge objects that are shared globally as well as those that are only shared within an app--all knowledge objects belong to a specific app, no matter how they are shared.

Note: App-level write permissions are usually only granted to users with admin-equivalent roles.

To sum up: the ability to edit a knowledge object has nothing to do with the ability to delete it. If you can't delete a particular knowledge object you may still be able to disable it, which essentially has the same function as knowledge object deletion without removing it from the system.

Deleting knowledge objects with downstream dependencies

You have to be careful about deleting knowledge objects with downstream dependencies, as this can have negative impacts.

For example, you could have a tag that looks like the duplicate of another, far more common tag. On the surface it would seem to be harmless to delete the dup tag. But what you may not realize is that this duplicate tag also happens to be part of a search that a very popular event type is based upon. And that popular event type is used in two important saved searches--the first is the basis for a well-used dashboard panel, and the other is used to populate a summary index that is used by searches that run several other dashboard panels. So if you delete that tag, the event type breaks, and everything downstream of that event type breaks.

This is why it is important to nip poorly named or defined knowledge objects in the bud, before they become inadvertently hard-wired into the workings of your deployment. The only way to identify the downstream dependencies of a particular knowledge object is to search on it, find out where it is used, and then search on those things to see where they are used--it can take a bit of detective work. There is no "one click" way to bring up a list of knowledge object downstream dependencies at this point.

If you really feel that you have to delete an knowledge object, and you're not sure if you've tracked down and fixed all of its downstream dependencies, you could try disabling it first to see what impact that has. If nothing seems to go seriously awry after a day or so, delete it.

Deleting knowledge objects in configuration files

Note that when you use manager, you can only disable or delete one knowledge object at a time. If you need to remove large numbers of objects, the most efficient way to do it is by removing the knowledge object stanzas directly through the configuration files. Keep in mind that several versions of a particular configuration file can exist within your system. In most cases you should only edit the configuration files in $SPLUNK_HOME/etc/system/local/, to make local changes on a site-wide basis, or $SPLUNK_HOME/etc/apps/<App_name>/local/, if you need to make changes that apply only to a specific app.

Do not try to edit configuration files until you have read and understood the following topics in the Admin manual:

PREVIOUS
Manage knowledge object permissions
  NEXT
About fields

This documentation applies to the following versions of Splunk® Enterprise: 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, 5.0.9, 5.0.10, 5.0.11, 5.0.12, 5.0.13, 5.0.14, 5.0.15, 5.0.16, 5.0.17, 5.0.18


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

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