Getting Data In

Is there anything I can do upstream to keep field names with dots?

Communicator

I've made a stupid.

I tried to make all of my field names a little more heirarchical and went to a field.subfield.subsubfield naming convention for my fields. Splunk no likey. A search for fun.time yields results, but fun.time=* yields none and the sidebar converts my dots to underscores.

Is there anything I can do upstream to keep these dots in my field names without all the ensuing funk?

Thanks!

-S

Labels (1)
1 Solution

Communicator

Communicator

Another gotcha is when using eval with the KV_MODE=xml in your props.conf for your sourcetype, you have to use the spath command to create new fields since the dots have a concatenation meaning.

0 Karma

Communicator

Splunk Employee
Splunk Employee

this needs an update!

I am sending index time fields ( kubernetes annotations ) and am able to search them with some considerations around how the SPL is crafted. It does work, in case anyone circles back in 2020

Splunk Employee
Splunk Employee

Hi! Here is something from the documentation that you might find useful.

http://www.splunk.com/base/Documentation/4.1.5/Admin/Transformsconf

CLEAN_KEYS = <bool>
* Option controlling whether the keys extracted at search time are cleaned. Key cleaning
  is defined as the replacement of non-alphanumeric characters with underscores. Leading 
  underscores and numbers are stripped.
* Defaults to true

Motivator

Why not use underscores instead of dots in your field names? 🙂

Motivator

I like that reply of yours.

0 Karma

Communicator

Because I want dots! Dots are pretty and dots are awesome! This is empirically* true. If I wanted underscores, I wouldn't have asked the question and would have instead said, "Hooray! I have an excuse to use underscores!" But that's not the case, and now I either need a .conf change I can make, or I'm going to have to pout and swing my arms around.

*Empirically is now a synonym for subjectively. This statement is beyond refudiation.