Getting Data In

What are some good methods for identifying dependencies between knowledge objects in Splunk?

Splunk Employee
Splunk Employee

This issue comes up when you need to delete an obsolete or duplicate tag, event type, transaction, or similar knowledge object. It also turns up in situations where you find you need to change the app context of an object (to change it from the Search app to the *nix app, for example).

If you have a tag that is used in an event type that appears in a saved search that in turn is the basis for a dashboard panel...how do you identify those dependencies and deal with them before deleting the tag?

Solid use case examples would be a great help here, but "best practices" advice would be useful as well.

1 Solution

Splunk Employee
Splunk Employee

For now it appears there's no easy way to manage this through Splunk Web. Until a better internal device comes along, the best way to identify dependencies with Splunk (if you haven't been keeping track of them with a spreadsheet or similar method--see bfaber's answer) is to search on the knowledge object in question in order to find the knowledge objects that are dependent on it, and then search on those objects to find their dependencies. It could take a bit of detective work, depending on how interconnected your knowledge objects are.

For example, if you have a tag named "roger1" you might search on it and find that it is used in three event types. You would then search on those event types to find the knowledge objects that use them--saved searches, other event types, etc. Along the way you might keep track of the dependent knowledge objects so you can repair the dependent objects if you decide to remove/rename "roger1."

If you want to delete a knowledge object but you're not sure whether you've tracked down 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 (or ask the object's owner to do so).

For more on the subject of knowledge object management via Splunk Web, see "Curate Splunk knowledge with Manager" in the Knowledge Manager Manual.

View solution in original post

SplunkTrust
SplunkTrust

stupid answer but honestly i usually just grep through $SPLUNK_HOME/etc to find dependencies. to answer little questions 'does anything actually use this savedsearch', or 'is there other view config and savedsearches config here that could benefit from a macro' etc..

But for a while we did have an instance we set up where we would index various splunk conf files and report on them. it would index each stanza as an event and each key as a kv pair etc.
There were definitely some drawbacks but we didnt spent that much time on it (grepping etc is fast)

And we werent monitoring the config live. If we were doing it live we'd have indexed with fschange and probably we would have had to do a little work at the search language level to only report on the most recent versions of everything. It's quite possible we or someone else could put together a little app with some dependency-finder tools like a macrofinder, eventtypefinder, savedsearchfinder, tagfinder etc..

Splunk Employee
Splunk Employee

I think a "dependency finder" app or add-on would be great, if you couldn't somehow work the functionality directly into Manager.

Splunk Employee
Splunk Employee

For now it appears there's no easy way to manage this through Splunk Web. Until a better internal device comes along, the best way to identify dependencies with Splunk (if you haven't been keeping track of them with a spreadsheet or similar method--see bfaber's answer) is to search on the knowledge object in question in order to find the knowledge objects that are dependent on it, and then search on those objects to find their dependencies. It could take a bit of detective work, depending on how interconnected your knowledge objects are.

For example, if you have a tag named "roger1" you might search on it and find that it is used in three event types. You would then search on those event types to find the knowledge objects that use them--saved searches, other event types, etc. Along the way you might keep track of the dependent knowledge objects so you can repair the dependent objects if you decide to remove/rename "roger1."

If you want to delete a knowledge object but you're not sure whether you've tracked down 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 (or ask the object's owner to do so).

For more on the subject of knowledge object management via Splunk Web, see "Curate Splunk knowledge with Manager" in the Knowledge Manager Manual.

View solution in original post

Communicator

MattNess: My deployment isn't too complex, but what I have been doing is this: I create a dictionary of eventtypes and tags that we have used by application. Before I roll a dashboard into production, I note any dependencies from that dashboard into the dictionary spreadsheet.

This works fine as I am the only developer, but I am not sure it would scale so well.

On my wishlist would be an automated way to manage all of this internally -- but dependencies would have to understand the difference between my prod dashboards and my dev/test ones.

HTH

0 Karma

Splunk Employee
Splunk Employee

Seems like as good an approach as any to manage dependencies as they develop at this point. See my answer for the official word on tracking down dependencies if you haven't been keeping track of them already.

0 Karma