Knowledge Manager Manual

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:

• About configuration files
• Configuration file precedence