Splunk Search

Can anyone confirm possible bug when using mvzip with xpath extracted fields?

siddharthprabhu
Explorer

Hello Splunk experts,

I am encountering strange behaviour when using mvzip on fields extracted using xpath commands.

I have provided a toy dataset below that mimics my XML events. I expect mvzip to combine the values in nickname and title pairwise. However, the search below creates only one pair and that too with the "wrong" set of values; the second value from nickname is combined with the first value from title. The other pair is not combined at all.

 

| makeresults 
| eval _raw="<foo><bar nickname=\"spock\" title=\"commander\"></bar></foo><foo><bar nickname=\"scotty\" title=\"engineer\"></bar></foo>"
| xpath outfield=nickname "//foo/bar/@nickname" field=_raw
| xpath outfield=title "//foo/bar/@title" field=_raw
| eval zipped=mvzip(nickname, title, "|")

 

When I use the same syntax on fields extracted via regular expressions, the output is correct. So, I'm suspecting that mvzip doesn't play nice with multivalue fields extracted using xpath.

Can anyone confirm if this is a bug or if I'm doing something wrong? I am running Splunk 8.1.3 in case anyone knows if this has been addressed in a later release.

Labels (1)
0 Karma
1 Solution

ITWhisperer
SplunkTrust
SplunkTrust

Looks like a bug with xpath (also present in 9.0.4) - xpath appears to join all mv fields in the events.

Try using spath (different syntax for path)

| makeresults 
| eval _raw="<foo><bar nickname=\"spock\" title=\"commander\"></bar></foo><foo><bar nickname=\"scotty\" title=\"engineer\"></bar></foo>"
| spath output=nickname "foo.bar{@nickname}"
| spath output=title "foo.bar{@title}"
| eval zipped=mvzip(nickname, title, "|")

View solution in original post

ITWhisperer
SplunkTrust
SplunkTrust

Looks like a bug with xpath (also present in 9.0.4) - xpath appears to join all mv fields in the events.

Try using spath (different syntax for path)

| makeresults 
| eval _raw="<foo><bar nickname=\"spock\" title=\"commander\"></bar></foo><foo><bar nickname=\"scotty\" title=\"engineer\"></bar></foo>"
| spath output=nickname "foo.bar{@nickname}"
| spath output=title "foo.bar{@title}"
| eval zipped=mvzip(nickname, title, "|")

PickleRick
SplunkTrust
SplunkTrust

It's not even that.

If you do

| eval tc=mvcount(title)
| eval nc=mvcount(nickname)

instead of the last eval, you'll see that for unknown reason only the nicknames are joined.

Some more digging into this shows that only the "title" attribute seems to _not_ get joined. Regardless of number of the attributes or their order.

0 Karma

siddharthprabhu
Explorer

Thank you! I have tried using spath before and it indeed does the job for simple extractions. However, I was trying to get the xpath approach to work because my real data is deeply nested with repeating node elements and I require complex xPath expressions to extract the fields of interest.

Oh well, at least I know I wasn't going crazy! Hopefully Splunk will fix this in a coming release.

0 Karma

burwell
SplunkTrust
SplunkTrust

Hi. It would be great to file a ticket with Splunk Support to make sure they are aware of the bug.

 

 

siddharthprabhu
Explorer

Sure, I'd be happy to. Could you please guide me on how to do that?

burwell
SplunkTrust
SplunkTrust

Hi @siddharthprabhu 

Whoever in your organization has access to create Splunk Support tickets can follow this https://community.splunk.com/t5/Random/How-do-i-file-a-Splunk-Support-Case-contact-Splunk-Support/td...

Thanks.

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...