Why manage Splunk knowledge?

Why manage Splunk knowledge?

If you have to maintain a fairly large number of knowledge objects across your Splunk deployment, you know that management of that knowledge is important. This is especially true of organizations that have a large number of Splunk users, and even more so if you have several teams of users working with Splunk. This is simply because a greater proliferation of users leads to a greater proliferation of additional Splunk knowledge.

When you leave a situation like this unchecked, your users may find themselves sorting through large sets of objects with misleading or conflicting names, struggling to find and use objects that have unevenly applied app assignments and permissions, and wasting precious time creating objects such as saved searches and field extractions that already exist elsewhere in the system.

Splunk managers provide centralized oversight of the Splunk knowledge. The benefits that knowledge managers can provide include:

• Oversight of knowledge object creation and usage across teams, departments, and deployments. If you have a large Splunk deployment spread across several teams of users, you'll eventually find teams "reinventing the wheel" by designing objects that were already developed by other teams. Knowledge managers can mitigate these situations by monitoring object creation and ensuring that useful "general purpose" objects are shared on a global basis across deployments.

For more information, see "Curate Splunk knowledge with Manager" in this manual.

• Normalization of event data. To put it plainly: knowledge objects proliferate. Although Splunk is based on data indexes, not databases, the basic principles of normalization still apply. It's easy for any robust, well-used Splunk implementation to end up with a dozen tags that all have been to the same field, but as these redundant knowledge objects stack up, the end result is confusion and inefficiency on the part of its users. We'll provide you with some tips about normalizing your knowledge object libraries by applying uniform naming standards and using Splunk's Common Information Model.

For more information, see "Develop naming conventions for knowledge objects" in this manual.

• Management of knowledge objects through configuration files. True knowledge management experts know how and when to leverage the power of Splunk's configuration files when it comes to the administration of Splunk knowledge. There are certain aspects of knowledge object setup that are best handled through configuration files. This manual will show you how to work with knowledge objects this way.

See "Create search time field extractions" in this manual as an example of how you can manage Splunk knowledge through configuration files.

• Setup and organization of app-level navigation for saved searches and reports, as well as views and dashboards. Left unmoderated, the navigation for saved searches, reports, views, and dashboards can become very confusing as more and more of these kinds of objects are added to Splunk applications. You don't have to be a Splunk app designer to ensure that users can quickly and easily navigate to the searches, reports, views, and dashboards they need to do their job efficiently.

For more information, see "Define navigation for saved searches and reports" in this manual.

• Review of summary index setup and usage. Summary indexes may be used by many teams across your deployment to run efficient searches on large volumes of data, but their usage also counts against your overall license volume. The knowledge manager can provide centralized oversight of summary index usage across your organization, ensuring that they are built correctly, used responsibly, and are shared as appropriate with users throughout your Splunk deployment.

Note: As of Release 4.1, summary index usage does not count against your overall license volume.

For more information, see "Use summary indexing for increased reporting efficiency" in this manual.

• Was this topic useful?
• Post a comment