My apologies. I was switching between two different approaches and the filters got crossed. To use the subsearch method above, modify that line to | where isnotnull(OS) index=A sourcetype="Any"
| ...
See more...
My apologies. I was switching between two different approaches and the filters got crossed. To use the subsearch method above, modify that line to | where isnotnull(OS) index=A sourcetype="Any"
| stats values("IP address") as "IP address" by Hostname OS
| append
[search index=B sourcetype="foo"
| stats values(Reporting_Host) as Reporting_Host]
| eventstats values(eval(lower(Reporting_Host))) as Reporting_Host
| where isnotnull(OS)
| mvexpand "IP address"
| eval match = if(lower(Hostname) IN (Reporting_Host) OR 'IP address' IN (Reporting_Host), "ok", null())
| stats values("IP address") as "IP address" values(match) as match by Hostname OS
| fillnull match value="missing" Depending on your deployment, combining the two index searches could improve performance, like this (index=A sourcetype="Any") OR (index=B sourcetype="foo")
| eventstats values(eval(lower(Reporting_Host))) as Reporting_Host
| where index != "B"
| mvexpand "IP address"
| eval match = if(lower(Hostname) IN (Reporting_Host) OR 'IP address' IN (Reporting_Host), "ok", null())
| stats values("IP address") as "IP address" values(match) as match by Hostname OS
| fillnull match value="missing" But eventstats and mvexpand could be bigger performance hindrances. There could be ways to avoid mvexpand; there could be ways to improve eventstats. But unless you can isolate the main contributor to slowness, they are not worth exploring. Performance is a complex subject with any querying language. You can start by doing some basic tests. For example, run those two subsearches separately and compare with combined search. If the total time is comparable, index search is the main hindrance. That will be very difficult to improve. Another test could be to add dedup before stats. And so on.