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
This basically tells me why I should go pound sand.
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.
This basically tells me why I should go pound sand.
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
Im back in 2021 🙂
The "considerations around how SPL is crafted" I alluded to means you either need to search using indexed field syntax, like
k8s.cluster.name::foo
or you need to configure fields.conf with your indexed fields as described in docs
https://docs.splunk.com/Documentation/Splunk/8.2.4/Data/Configureindex-timefieldextraction#Where_to_...
Or finally, as we currently do in Cloud, presumably as a tradeoff for customer experience vs performance worries...
always_include_indexedfield_lispy = <boolean>
* Whether or not search always looks for a field that does not have
"INDEXED = true" set in fields.conf using both the indexed and non-
indexed forms.
* If set to "true", when searching for <field>=<value>, the lexicon is
searched for both "<field>::<value>" and "<value>".
* If set to "false", when searching for <field>=<val>, the lexicon is
searched only for "<value>".
* Set to "true" if you have fields that are sometimes indexed and
sometimes not indexed.
* For field names that are always indexed, it is much better
for performance to set "INDEXED = true" in fields.conf for
that field instead.
* Default: false
As always, being lazy is fun, but will cost perf. Setting the fields.conf is definitely preferable, especially when the fields don't change very much and just take a little bit of up front work/planning.
choose your weapon wisely, friends...
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
Why not use underscores instead of dots in your field names? 🙂
I like that reply of yours.
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.