We have a parent search that looks like -
index=os_linux *
| eval length = len(process)
| where length = 7
| search process!= <conditions>
| dedup process dest
| table process dest cmd_syslog2 _raw
Instead of the table we would like to issue a sub search and pass in the dest and process as parameters.
The sub-search is -
index=os_linux
| eval length = len(process)
| where length = 7
| search dest=<dest> process=<proces>
| dedup _raw
| table process dest _time cmd_syslog2 _raw
| sort +_time
I hope it makes sense ...
Hi @richgalloway,
The following works for us -
index=os_linux
[ search index=os_linux | eval length = len(process) | where length = 7 | fields dest, process | rename dest as search | format ]
| dedup _raw
| sort + _time
| table process dest _time cmd_syslog2 _raw
By adding | rename dest as search
the generated sub-search is in pairs of process and dest, otherwise it generated only the process field, which is causing more results.
I think we have a terminology problem. A "subsearch" is a search within a search. Subsearches always execute first so it's not possible to pass anything from the parent to a subsearch. You can, however, pass data from subsearch to parent. Let's turn your query around and see if it does what you want.
index=os_linux
[ search index=os_linux | eval length = len(process) | where length = 7 | fields dest, process | format ]
| dedup _raw
| sort + _time
| table process dest _time cmd_syslog2 _raw
The subsearch returns a string like ((dest=foo process=barbarb) OR (dest=abc process=xyzzyzx))
, which is then processed in the parent search and should produce the desired results.
I'm not entirely certain the subsearch is needed. Have you tried the simple version of the search?
index=os_linux
| eval length = len(process)
| where length = 7
| dedup _raw
| sort + _time
| table process dest _time cmd_syslog2 _raw
@richgalloway, it seems the subsearch hits some limitations. If that's the case, where would they be reported? I don't see them via the Inspect Job...
Yes, subsearches are limited to 50,000 events. There are settings in limits.conf to change them, but usually it's better to refine the search. You can try dedup
to reduce the number of events returned from the subsearch.
Have you tried the second search I offered?
Great, but if we hit the limit, where is it being reported?
It should be in the search log.