I happened to work this out for someone else yesterday. What you really want is "lookup file contains the results of the last non-empty job run, right? So basically, you include in the lookup the time of the run (or of the data set or whatever). In mine below, I just take it as the job run time: ... | eval jobtime=now() | inputlookup append=true mylookup | sort 0 - jobtime | streamstats max(jobtime) as latestjobtime | head (jobtime==latestjobtime) null=t | fields - latestjobtime | outputlookup mylookup Now the trick is that the part of the search before eval (the ... ) needs to either return the last valid set, or else no results at all. So if you have a daily upload, and you run your base search from -1d@d to @d each day, that should work fine. ... View more

You can't just call an arbitrary script in a search pipeline. The script must know how to accept Splunk pipeline inputs (unless it ignores them, which yours appears to do, so that's fine), but more importantly it must output them in the right format. As it turns out, the output format is a standard CSV file, including a header that specifies the field names. So basically you need to add a print for the CSV file header that matches the fields you're outputting. In general, you'll be a lot better off using the language-specific CSV libraries as well, rather than printing directly. Also, I imagine you understand that this computation can be done in Splunk search language directly and you're merely going through an exercise of getting a simple command to work. ... View more

... | dedup id will do it. ... View more

You're going to have to do a workaround by changing your external commands. You can change the call to ssh if you're using bash from: ssh abc defg hijk to LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH ssh abc defg hijk if you're using Linux, to make sure the OS checks the default system path before it the Splunk path. If you have multiple calls to ssh or other commands that use openssl shared libraries, you can instead just export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH at the top of your script instead. ... View more

There are several ways to do this, and you don't need to screw around with finding field values. You can do it the most crude way: index=here sourcetype=this SpecialKeyword | stats count as c_special | append [ search index=here sourcetype=this SqlTransactionRollbackException AND CertainCommandObject | stats count as c_other] | eval ratio=c_other/c_special But you can refactor to make the search more efficient, which was kind of what you were trying: index=here sourcetype=this (SpecialKeyword OR (SqlTransactionRollbackException AND CertainCommandObject)) | stats count(searchmatch("SpecialKeyword")) as c_special count(searchmatch("SqlTransactionRollbackException AND CertainCommandObject")) as c_other | eval ratio = c_other/c_special The searchmatch() function lets you just use the same search terms as before (just a substitute for the looking for a SQLSTATE value or other field), though it makes a bunch of redundancy and makes it harder to see what you're doing. But the overall search will be faster. Another way to solve this makes use of the multisearch search command. It's arguably clearer than the above refactoring, and the good thing is it doesn't have the redundancy: | multisearch [ search index=here sourcetype=this SpecialKeyword | eval marker="s" ] [ search index=here sourcetype=this SqlTransactionRollbackException AND CertainCommandObject | eval marker="o" ] | stats count(eval(marker=="s")) as c_s count(eval(marker=="o")) as c_o | eval r=c_o/c_s This is pretty much what you were trying to do, except without you having to try to find a special marker field (you just create it with | eval marker=... ) and without having to redundantly specify search terms (which is what i did above). You also get the improved performance of not having to dispatch two searches in sequence (which is what the version with append ), as Splunk does the refactor and runs both multisearches in a single pass. ... View more

index=all_results NOT [ search index=bad_results | return 10000 key ] if you have 10000 or fewer distinct keys in bad_results or: index=all_results OR index=bad_results | stats count(eval(index=="bad_results")) as b by key | where b<1 doesn't appear simpler than yours, but it runs better if you have a multi-node Splunk system. on the other hand, it doesn't return the whole item, just the key, though you can fix that by adding first(otherfield) as otherfield to the stats command. ... View more

The same considerations apply for Splunk as for relational databases. It depends how you're planning to use it. If you are performing rare searches, a slightly smaller block size may improve performance, because you're not transferring as much data. If you're performing dense searches and reports, you may read fewer blocks, though this effect is probably not large as the block reads are likely to be sequential. Either way though, with filesystem block sizes in the normal range of 4kb to 64kb and with modern disk sizes and disk transfer times, this is unlikely to make a measurable difference. ... View more

[Edited to reflect that SSL may not need to be disabled] As noted in the comments, it looks like this is because of SSL setup time, and particularly sequential SSL time. If you have significant latency between the search head and indexers, you'll see this. When using SSL by default, Splunk sets up connections to each indexer sequentially (though once set up, the searches run in parallel of course). It is possible to set up connections in parallel. You should do this by setting: On the search head limits.conf: [search] multi_threaded_setup = true Additionally, in versions of Splunk 5.0.3 and older, and possibly in more recent ones, the SSL implementation would not work reliably with multi_threaded_setup enabled. (This is why it is not enabled by default.) So in those, you will have to disable SSL between the search head and indexers. In newer versions, it should work okay, but the fix has not been thoroughly verified. if you run into problems on the newer versions, you should try without SSL also. To turn off SSL properly, you should set: On the indexer server.conf: [settings] enableSplunkdSSL = false On the search head server.conf: [general] useHTTPClientCompression = on-http On the search head distsearch.conf: [distributedSearch] trySSLFirst = false ... View more