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!

Introducing Splunk Enterprise 9.2

WATCH HERE! Watch this Tech Talk to learn about the latest features and enhancements shipped in the new Splunk ...

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...

Routing logs with Splunk OTel Collector for Kubernetes

The Splunk Distribution of the OpenTelemetry (OTel) Collector is a product that provides a way to ingest ...