In my data, events can have children. There is data in those events that I would want to associate with the parent event. When I do my base search, sometimes I find events where the parent event is created outside of the global time picker window. The only way I can think to solve this is by I can join a sub-search and have the sub-search be a different time window?
My existing search is as follows:
"base search with sourcetype=A"
| rename display_value as parent_num
| join type=outer parent_num
[search "second search with sourtype=A"
| dedup number sortby -sys_updated_on
| rename priority as parent_priority, number as parent_num, u_incident_type as type,
| table parent_num, parent_priority, type, parent_assignment]
| eval type = if(parent!="*", u_incident_type, type)
This works, except when, for example, if I am looking at the past 24 hours, and the "parent" was created before. I am sure there are a number of ways to solve this, but this seems most apparent to me. I don't want to exclude the occasions when I am "missing" the data.
Hi swangertyler,
Don't use join
for reasons.
Use multisearch
instead, it will not hit any hidden limits without telling you.
Try something like this:
| multisearch
[ search "base search with sourcetype=A" earliest=-1d@d latest=-0d@d
| rename display_value as parent_num ]
[ search "second search with sourtype=A" earliest=-3d@d latest=-2d@d
| rename priority as parent_priority, number as parent_num, u_incident_type as type ]
| dedup number sortby -sys_updated_on
| table parent_num, parent_priority, type, parent_assignment
| eval type = if(parent!="*", u_incident_type, type)
might need some tweaking to make it fully work, but you get an idea how it works.
hope this helps ...
cheers, MuS
I could not get this to work satisfactorily. I ended up taking what I wanted as the second search, and using a report to make a csv, then joining on an inputlookup. Curating the search and sending it to a csv should keep me from running into any of those secret limits from joins.
I have yet to figure out how to get multisearch to work as I need it to.
It will still hit secret limits of the number of rows returned by the csv exceeds whatever your maximum rows a subsearch can return is set to. If you are curating the data to a csv beforehand I'd just use the lookup command since it's already a lookup
That is a good idea/point. Do I gain anything else from using a lookup vs. join [|inputlookup etc]?
I do not think in my case that I will hit any limits.