topic Re: Best practices when using subsearch (eval, etc) in Splunk Search

Best practices when using subsearch (eval, etc)

ohlafl — Tue, 28 Jul 2015 12:31:16 GMT

I am relatively new to Splunk and would like to get a better sense of using subsearch as I can see how valuable it must be if you could fully utilize it. I would like to know some of the best practices when using subsearch in general but more specifically within eval-statements, how to think in order to get the right data out of the subsearch.

What does a subsearch actually return? It of course depends on what you put in the search query but how does an eval-statement interpret the result? Depending on if the subsearch ends with return, table someValue, head 1 or just a bunch of event or statistic-lines, how it is interpreted? How does a subsearch result containing multiple fields differ from a subsearch that only returns one field?

What are the best practices for returning a specific value of a field to use within an if statement? Something like this: eval cowStatus=if([subsearch returning current number of cows] > 50, "Cow overload!", "All cool")

I hope my questions are not to broad.

Re: Best practices when using subsearch (eval, etc)

acharlieh — Tue, 28 Jul 2015 12:59:35 GMT

It seems to be a pretty broad question... it sounds like you could be looking for the documentation on the return command or for the format command docs, which is used implicitly at the end of a subsearch? Or for the docs on how to change subsearch results?

Re: Best practices when using subsearch (eval, etc)

somesoni2 — Tue, 28 Jul 2015 14:48:47 GMT

In general, the subsearch would return the results of a search, and the format is also decided by the code/subsearch query (you code that based on your requirement of subsearch usage)

e.g. index=_internal [search index=_internal | top 2 sourcetypes | table sourcetype]  
 **This will return results with a field name 'sourcetype' and add as filter condition. so the resulting search would become (sample)
index=_internal (sourcetype=splunkd OR sourcetype=splunkd_access)

Same this if you reduce the result count of subsearch to 1 and use return,

index=_internal [search index=_internal | top 1 sourcetypes | return $sourcetype ] 
**This would return a string with value of sourcetype into the place its used. SO the resulting search would become (sample) [THis is what we used when using subsearch with eval]
index=_internal "splunkd"

Re: Best practices when using subsearch (eval, etc)

woodcock — Mon, 03 Aug 2015 12:53:18 GMT

I think the general answer to your question is that you should try to avoid using a subsearch whenever possible. The minor reason is performance but the major reason is that it has some hard limits that cannot be overcome. In the case of a join-type problem, you should bend over backwards to use stats instead and this is usually possible. In the case of the example you gave, if the subsearch spans a large set of events (a long period of time) and/or you are going to run the same search frequently, it would probably be best to schedule a separate saved-search and write the results of the animal count to a lookup file using the outputlookup command and then your search would look something like this:

eval cowStatus=if([|inputlookup animal_counts.csv | where animal="cow" | return $count] > 50, "Cow overload!", "All cool")