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 software. 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 reports and field extractions that already exist elsewhere in the system.

Splunk knowledge managers provide centralized oversight of Splunk software 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 Monitor and organize knowledge objects.

• Normalization of event data. To put it plainly: knowledge objects proliferate. Although Splunk software 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 the Splunk Common Information Model.

For more information, see Develop naming conventions for knowledge objects.

• Management of knowledge objects through configuration files. Some aspects of knowledge object setup are best managed through configuration files. This manual will show Splunk Enterprise knowledge managers how to work with knowledge objects in this way.

See Create and maintain search-time field extractions through index files as an example of how you can manage Splunk knowledge through configuration files.

• Creation of data models for Pivot users. Splunk software offers the Pivot tool for users who want to quickly create tables, charts, and dashboards without having to write search strings that can sometimes be long and complicated. The Pivot tool is driven by data models--without a data model Pivot has nothing to report on. Data models are designed by Splunk knowledge managers: people who understand the format and semantics of their indexed data, and who are familiar with the Splunk search language.

See About data models for a conceptual overview of data model architecture and usage.

• Manage setup and usage of summary-based search and pivot acceleration tools. Large volumes of data can result in slow performance for Splunk software, whether you're launching a search, running a report, or trying to use Pivot. To speed things up the knowledge manager can make use of report acceleration, data model acceleration, and summary indexing to help ensure that the teams in your deployment can get results quickly and efficiently. This manual shows you how to provide centralized oversight of these acceleration strategies so you can ensure that they are being used responsibly and effectively.

For more information, see Overview of summary-based search and pivot acceleration.