Reporting

Why does saved search get corrupted

andiih
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

jrodman
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

jrodman
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

tskimball
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

tskimball
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

andiih
Explorer

have you found any way around it yet ?

0 Karma

Branden
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

andiih
Explorer

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

0 Karma

Branden
Builder

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

0 Karma

andiih
Explorer

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

0 Karma

andiih
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
Get Updates on the Splunk Community!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...