The power of Splunk is driven by the user. At its core, Splunk is a set of user-defined searches, fields, reports, etc. All of these defined components of Splunk, the functions that really enrich your data, are knowledge objects. Basically, if you’re using Splunk, you’re using a knowledge object. With those knowledge objects, you can utilize tags and technical add-ons to clean up and maintain your data.
The Knowledge Object Basics
A knowledge object could be a piece of the search or a piece of the data they’re ingesting, or just a group of data. A Splunk App is simply a collection of knowledge objects. When defining your knowledge, ask yourself and your teams, “What do I want Splunk to show me?”
To better identify your data, utilize your field extraction to pull from the data coming in. Let’s use the example of the identifier, “transaction ID.” You want to see all information relevant to the transaction ID extracted. To start, you create a field extraction around the knowledge object, transaction ID, and now you can search for that specific set of information.
Knowledge objects exist in the deployment, indexers, search heads, saved searches, and any other user-defined data with your Splunk instance. You can reference a knowledge object any time you’re trying to isolate down your data to a refinement point.
Tag, You’re It!
To make your knowledge objects stick, using the tagging function. In most cases, you want to give your data an identifiable name. Tags can help you centralize the naming conventions behind your data and knowledge objects.
We’ll stick with the example of transaction ID, used above. In this scenario, you have multiple streams of data coming in. This transaction ID comes in through the firewall, hits your web server, goes into your database, and then transfers back through. If you have a transaction ID throughout that stream, you can tag each knowledge object at each index point. Because your firewall is the one sending data in, you’ll want to tag your transaction ID within that point. On your web server, you can tag that knowledge object with the same transaction ID. The same goes for your database. Now, when you search on that transaction ID, Splunk will pull up that transaction ID for all of those data inputs.
To maintain a common naming convention, tag your data early on.
Finally, let’s throw in technical add-ons and how they work in tagging to knowledge objects. When you have a known data type coming in, you can implement a technical add-on. This add-on will take the data, ingest it, and apply known rules to it.
We can look at firewalls as an example. If you have a known firewall bender, you can apply the technical add-on for the known firewall bender. By adding a technical add-on, your data is now CIM compliant. The technical add-ons take the data coming in from the firewall, tag it, and perform a field alias.
The technical add-ons use event data and group the data sets by common terms instead of the vendor term. How is this helpful? The ability to search by common terms allows for easier communication flow across teams. Common terminology, via the Common Information Model (CIM), helps with communication across vendors and teams.
We Can Help
Kinney Group has the ability to automate this flow for our customers and support it with Expertise on Demand. We have the best practice knowledge to make your data stick, seamlessly. We know some of these tips may not fall as first priority on the long list of Splunk fixes for your team, that’s where we can jump in. Take your time to resolution down to the minute and utilize a support service like EOD. Fill out the form below to chat with one of our expert Splunkers.