Reporting

Why does saved search get corrupted

Explorer

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 ?

Tags (1)
1 Solution

Splunk Employee
Splunk Employee

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

View solution in original post

Splunk Employee
Splunk Employee

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

View solution in original post

New Member

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.

0 Karma

New Member

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. 🙂

0 Karma

Explorer

have you found any way around it yet ?

0 Karma

Builder

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?

0 Karma

Explorer

thanks - I'll try an upgrade and see if its fixed.

0 Karma

Builder

I just upgraded to 4.1.5, but I believe I was at 4.1.4 when I tested your query.

0 Karma

Explorer

Branden, what version of splunk are you running where this kind of query works ?

0 Karma

Explorer

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.

0 Karma