Splunk® Enterprise

Knowledge Manager Manual

Splunk Enterprise version 7.3 is no longer supported as of October 22, 2021. See the Splunk Software Support Policy for details. For information about upgrading to a supported version, see How to upgrade Splunk Enterprise.

Disable or delete knowledge objects

Your ability to delete knowledge objects in Splunk Web depends on a set of factors:

  • You cannot delete default knowledge objects that were delivered with Splunk software (or with an app).
    If the knowledge object definition resides in a default directory, it can't be removed through Splunk Web. It can be disabled by clicking Disable for the object in Settings. Only objects that exist in an app's local directory are eligible for deletion.
  • You can always delete knowledge objects that you have created, and which haven't been shared by you or someone with admin-level permissions.
    Once you share a knowledge object you've created with other users, your ability to delete it is revoked, unless you have write permissions for the app to which they belong.
  • To delete any other knowledge object, your role must have write permissions for the app to which the knowledge object belongs.
    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.

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

If a role does not have write permissions for an app but does have write permissions for knowledge objects belonging to that app, it can disable those knowledge objects. Clicking Disable for a knowledge object has the same function as knowledge object deletion, with the exception that Splunk software does not remove disabled knowledge objects from the system. A role with write permissions for a disabled knowledge object can re-enable it at any time.

There are similar rules for data models. To enable a role to create data models and share them with others, the role must be given write access to an app. This means that users who can create and share data models can potentially also delete knowledge objects. For more information, see Manage data models.

Grant a role write permissions for an app

If your role has admin-level permissions, you can grant a role write permissions for an app in Splunk Web. Once a role has write permissions for an app, users with that role can delete any knowledge object belonging to that app.

Users whose roles have write permissions to an app can delete knowledge objects that belong to that app. This is true whether the knowledge object is shared just to the app, or globally to all apps. Even when knowledge objects are shared globally they belong to a specific app.

For more information, see Manage knowledge object permissions.

Steps

  1. From the Splunk Home page, select any app in the Apps Panel to open the app.
  2. Click on the Applications menu in the Splunk bar, and select Manage Apps.
  3. Find the app that you want to adjust permissions for and open its Permissions settings.
  4. Select Write for the roles that should be able to delete knowledge objects for the app.
  5. Click Save to save your changes.

You can also manage role-based permissions for an app by updating its local.meta file. For more information see Setting access to manager consoles and apps in Securing Splunk Enterprise.

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 reports--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 fix poorly named or defined knowledge objects 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 a 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 breaks after a day or so, delete it.

Deleting knowledge objects in configuration files

In Splunk Web, 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:

Last modified on 29 May, 2020
Manage orphaned knowledge objects   About Splunk regular expressions

This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.11, 8.1.13, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 9.4.0, 8.1.10, 8.1.12, 8.1.14, 8.1.2


Was this topic useful?







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