If I save the following search as mysearch (sources and rule numbers changed to protect the innocent)
((sourcetype="fred" AND (rule_number="1" OR rule_number="2" OR rule_number="3")) OR (severity>10 AND rule_number!="4"))
then try to run it from searches & reports / mysearch
I get the following back...
(severity>10 ((sourcetype="fred" AND (rule_number="1" OR rule_number="2" OR rule_number="3")) OR AND rule_number!="4"))
which has been refactored to gibberish. What's going on? How can I write that search so it doesn't get broken ?
The simple test for search decomposition problems (what this looks like) is to enter the search in the summary view, and see what it looks like in the flashtimeline view.
Search decomposition is going away forever in 4.2, but in 4.1.5 you could try, in web.conf in your app (or globally in system/local)
[settings]
disabled_decomposers = addtermgt
The simple test for search decomposition problems (what this looks like) is to enter the search in the summary view, and see what it looks like in the flashtimeline view.
Search decomposition is going away forever in 4.2, but in 4.1.5 you could try, in web.conf in your app (or globally in system/local)
[settings]
disabled_decomposers = addtermgt
I am having a similar issue. 4.1 build 77833, Linux (my forwarders [from Solaris] are newer, if that matters any).
Saved Search-->
Mon_Func="proc" Mon_CPU_Perc>0 | transaction fields="Mon_Proc_Pid" maxspan=12h | search linecount > 1
Called up in the dropdown, it looks like this-->
Mon_Func="proc" | transaction fields="Mon_Proc_Pid" maxspan=12h | search linecount > 1 Mon_CPU_Perc>0
The second half of the initial search gets moved to the end, which generates a totally different result. I've confirmed in the conf files that the saved search is the 'correct' one.
For mine, the search entry for Mon_CPU_Perc needed to be changed as a >= format, instead of plain ">".
So change your severity comparison to be a >= format and see what happens.
The reason for this oddness is due to what jrodman has mentioned below, and I'm looking forward to 4.2 due to this. 🙂
have you found any way around it yet ?
Weird... I can't seem to reproduce that. What version of Splunk are you running? When you say "refactored to gibberish", are you referring to the "re-structuring" of the query that you show? Or is it garbled/unreadable?
thanks - I'll try an upgrade and see if its fixed.
I just upgraded to 4.1.5, but I believe I was at 4.1.4 when I tested your query.
Branden, what version of splunk are you running where this kind of query works ?
I'm refering to the second query I get back, with the bad restructuring, resulting in severity>10 being moved to the beginning, brackets being moved around and "OR AND" towards the end.
I'm running 4.1.2, build 79191 on Windows.