Splunk Search

Fields with '=' as value stored in summary index are not extracted

darshan
Observer

I am storing a certain dataset in summary index which has some events with fields where the values are '=' or '=='. When searched, these events does not such fields. 

I managed to replicate this by doing this,

| makeresults 
| eval testval1 = "="
| eval testval2 = "=="
| eval testval3 = "-"
| eval testval4 = "--"
| eval testval5 = "*"
| eval testval6 = "/"
| table testval*
| summaryindex index="a_summary_index" name="testval"
which returns,
testval1testval2testval3testval4testval5testval6testval7testval8
===-

--

*/+++
 
index="a_summary_index" source="testval" 
| table testval*

 returns,

testval1testval2testval3testval4testval5testval6testval7testval8
  ---*/+++

 

(where the testval1 and testval2 are null). The raw event looks like this,

 

 

testval1="=", testval2="==", testval3="-", testval4="--", testval5="*", testval6="/", testval7="+", testval8="++"

 

 

The sourcetype is by default (as all other configurations) is stash.

Field extractions configuration is,

 

[stash_extract]
DELIMS = ",", "="
CAN_OPTIMIZE = false
MV_ADD = true
CLEAN_KEYS = false

 

I was wondering if there will be any implications on other search features if the above stanza is modified (since this is default configuration). Any feedbacks or suggestions are much appreciated.

Labels (2)
0 Karma
Get Updates on the Splunk Community!

Deep Dive into Federated Analytics: Unlocking the Full Power of Your Security Data

In today’s complex digital landscape, security teams face increasing pressure to protect sprawling data across ...

Your summer travels continue with new course releases

Summer in the Northern hemisphere is in full swing, and is often a time to travel and explore. If your summer ...

From Alert to Resolution: How Splunk Observability Helps SREs Navigate Critical ...

It's 3:17 AM, and your phone buzzes with an urgent alert. Wire transfer processing times have spiked, and ...