We have a use-case where responses(host_addr) returned from DNS queries are passed through AbuseIPDB API to check for any potential matches. Since the API has a set limit we dont want to query an IP more than once. To achieve this, stats is used to get distinct values and then it is passed through the API. It works well but due to the use of "stats", we lose all the other crucial fields from the original data, e.g. src_ip, query etc. Here's a sample query:
Could eventstats come to the rescue here? If so, what could be a potential syntax of that search? From the other examples I saw, eventstats sees to be more useful when performing a actual stats function like sum etc.
eventstats doesn't seem likely as the abuse API seems to only take a single IP address.
A couple of possibilities, one to use join, so in the subsearch you can do the base search and the lookups as you are currently doing and then the outer search will join with the subsearch on host address, but join is not a good solution as there are resource limits you may hit.
An alternative, which may work could be to run an appendpipe subsearch. The difference with that is that the appendpipe subsearch is run after the main search. In that search, you could do the stats/abuseip calls and then a further stats after that which merges the values from the appendpipe into their corresponding row, something like
| stats count by src_ip, query, host_addr
| appendpipe [
| stats count by host_addr
| abuseip ipfield=host_addr
| sort - host_addr
| filldown query src_ip
| stats values(LastReportedAt) as LastReportedAt values(AbuseConfidence) as AbuseConfidence by src_ip, query, host_addr