This is a fantastic case study of how Splunk handles major breaker tokens. Splunk is representing the field, jobName as containing "(W6)" truncating the remainder of the value. I don't believe it is terminating because of the ") " in the value. After examining how other fields are extracted in this sample, I am convinced that it terminates the string exactly because the ")" closes the opening "(". I'm sure this is described in some linguistic documents but I don't know how to find them. So here's a series of tests to observe. The simplest case: | makeresults
| eval _raw = "no_separator=abcdef, quote1 = \"abc\"def, quote2 = 'abc'def, bracket1=(abc)def, bracket2=[abc]def, bracket3 = {abc}def, white_space=abc def"
| extract kvdelim="=" pairdelim=, Here, I'm explicitly prescribing kvdelim and pairdelim to avoid additional weirdness. bracket1 bracket2 bracket3 no_separator quote1 quote2 white_space (abc) [abc] {abc} abcdef abc 'abc' abc The second one is perhaps trivial except I added a trailing comma after whitespace entry: | makeresults
| eval _raw = "quote1a = abc\"def\", quote2a = abc'def', bracket1a=abc(def), bracket2a=abc[def], bracket3a = abc{def}, white_space1=abc def,"
| extract kvdelim="=" pairdelim=, bracket1a bracket2a bracket3a quote1a quote2a white_space1 abc(def) abc[def] abc{def} abc"def" abc'def' abc def By adding a trailing comma, white_space1 now includes the part after white space. Among these, white space behaviors are the most intriguing. So, the following is dedicated to its weirdness: | makeresults
| eval _raw = "white_space2=abc def, white_space3 =abc def, white_space4= abc def, white_space5 = abc def, white_space6 = abc def, white_space7 = abc def,"
| extract kvdelim="=" pairdelim=, white_space2 white_space3 white_space5 white_space6 white_space7 abc def abc def abc def abc abc def Here, you see some dynamics between white space(s) before and after "="; white space(s) before and after the first consequential non-space string also have some dynamics. White space dynamics also affects other brackets. Double quote is perhaps the best protection of intention: | makeresults
| eval _raw = "quote1b=\"abc\" def, quote1c =\"abc\" def, quote1d= \"abc\" def, quote1e = \"abc\" def, quote1f = \"abc\" def, quote1g = \"abc\" def,"
| extract kvdelim="=" pairdelim=, quote1b quote1c quote1e quote1f quote1g abc abc abc abc abc The takeaway from all these is that developers need to express their intention by properly quote values and, like @PickleRick suggests, judiciously use white spaces. Unprotected strings are subject to wild guesses by Splunk - or any other language. To joggle Mark's memory: Pierre had launched an initiative to encourage/beg developers to standardize logging practice so logs are more Splunk-friendly. (I would qualify this as "machine-friendly", not just for Splunk.) Any treatment after logs are written - such as the workaround @livehybrid proposes, is bound to be broken again when careless developers make random decisions. Your best bet is to carry on the torch and give developers a good whip.
... View more
