I am trying to edit Summary Index for the scheduled search. I am getting the following error message:
This saved search cannot perform summary indexing because it has a malformed search.
There are no problems with the search as I can run it manually without issues.
Has anyone else experienced the same error message?
Mostly you are trying to use macros or other knowledge objects which are not shared in search app , please expand the macros or give them share permission and try to save it again. I had exactly same issue.
I've tested every lookup used in my search, still getting the error. Not using any macros.
My lookups were tested by first double checking all the permissions, they're all set to global and read for anyone. But to double check other non-obvious issues, I removed them one at a time. My search is still malformed.
I have some subsearches (both are used to pull in lookup tables) and I tried removing those as well.
Search that's repeatedly reported as malformed is
index=idp-thing OR (sourcetype=other-idp AND application!=dns) OR host=yet-more-idp OR sourcetype=ddos-thing | eval src_ip=coalesce(src,src_ip), dest_ip=coalesce(dst,dest_ip) | search NOT [|inputlookup AUTHORISED-VULN-SCANNERS.csv | table SUBNET | rename SUBNET as src_ip] | eval ATTACK_TYPE=coalesce(msg,attack,attack_name,attackname,threat,EventName) | eval QUERY = [ | inputlookup IDP-IGNORE.csv | eval ATTACKSRCH=ATTACK."|" | stats values(ATTACK) as ATTACK | mvcombine delim="|" ATTACK | rex mode=sed field=ATTACK "s/\| /|/g" | rex mode=sed field=ATTACK "s/\|$//g" | eval QUERY="\"(".ATTACK.")\"" | return $QUERY ] | where !match(ATTACK_TYPE, QUERY) | lookup agencyiplookup SUBNET as src_ip OUTPUT CLIENT as SRCORG | search SRCORG="UNKNOWN" | lookup agencyiplookup SUBNET as dest_ip OUTPUT CLIENT as ORG | sistats count(src_ip) as COUNT, values(ATTACK_TYPE) as ATTACKS by src_ip, ORG
Sourcetypes etc mildly sanitized.
This is a search I'm migrating from one splunk system (7.2.3) to a newer splunk system (7.3.0) and not having it work is a tad frustrating.
Well, I solved my issues by just keeping at it.
So, I'm migrating searches from one splunk to another, and this one ain't mine, so it took me a while to wrap my head around what it's doing.
I'm not sure why splunk has changed it's mind about this, but now that I've found the issue, I'm inclined to agree.
The middle section with eval QUERY = [subsearch] exists to take a bunch of entries in a table and build a regex of pipes to OR the text. A simple
| search NOT [ subsearch outputting fields using the matching fieldname] works to do exactly that, without regex. IFF the entries included regex I gues I would have needed to do a new field and make sure the entries don't match the table's entries, which would make it slightly more complex, but the issue appears to have been simply a weird way of doing things.
Hoorah for migrating other people's stuff.