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 (see the next point).
- To delete any other knowledge object, your role must have write permissions for:
- The app to which the knowledge object belongs.
- The knowledge object itself.
- 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.
Note: 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.
1. Click the App dropdown at the top of the page and select Manage Apps to go to the Apps page.
2. On the Apps page, find the app that you want to grant write permissions for and click Permissions.
3. On the Permissions page for the app, select Write for the roles that should be able to delete knowledge objects for the app.
4. Click Save to save your changes.
You can also manage role-based permissions for apps by updating the app's
local.meta file. For more information see Setting access to manager consoles and apps in the Securing Splunk Enterprise manual.
Grant a role with app write permissions the ability to delete a knowledge object that belongs to that app
Once a role has write permissions for an app, users with that role can delete any knowledge object belonging to that app as long as they also have write permissions for those objects. Users can do this 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.
This procedure assumes that:
- Your role has admin-level permissions.
- The role that you are setting object-level permissions for has the ability to write to the app that the object belongs to.
1. Navigate to the listing page for the knowledge object in Settings.
2. To ensure that you are viewing objects that belong to the app for which the role has write permissions , select the app name or All for the App context.
3. On the listing page, locate the knowledge object that the role needs to be able to delete and click its Permissions link.
4. On the permissions page for the knowledge object, select Write for the role.
If you have followed this procedure and the procedure that came before it you the role should be able to delete the knowledge object.
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 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 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 seems to go seriously awry after a day or so, delete it.
Deleting knowledge objects in configuration files
Note that 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:
Resolve orphaned searches, reports, and alerts
This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2