topic Re: Has anyone experienced values shifted to the wrong field when displaying a KV Store Lookup table in a dashboard? in Dashboards & Visualizations

Has anyone experienced values shifted to the wrong field when displaying a KV Store Lookup table in a dashboard?

codiceluna — Tue, 09 Apr 2019 21:56:47 GMT

When displaying fields from my KV Store Lookup in a dashboard the values of one field are not displaying and subsequent values from subsequent fields to shift to the right. I've moved columns around and infinity checked my fields to no avail.

Doing a standard search using | inputlookup etc. displays all values where they should be.

I have a number of filters requiring sub-searches but none of them have fields that don't exist in the base search.
I'm using table and fields in my base search and I understand that transforming searches are recommended but they are not practical here and it doesn't help.
I tried fillnull to see if null values were a problem and while the null values are useful to see it doesn't show a cause. The column with the missing values contains non-null values regardless.

example:

| inputlookup mylookup
| eval key=_key
| table _Key,field1,field2,field3,field4,field5,field6,field7,field8
| search field1="*$token1$*" field2="*$token2$*"

before the html form i have [field1,field2,field3,field4,field5,field6,field7,field8]
table as displayed

field1 field2 field3 field4,field5,field6,field7,field8,field9, field10
val1   val2    val3     val4              val7    val8   val9   val10

I appreciate the assist.

Re: Has anyone experienced values shifted to the wrong field when displaying a KV Store Lookup table in a dashboard?

codiceluna — Tue, 09 Apr 2019 22:07:59 GMT

Correction to the above table display example

field1 field2 field3 field4,field5,field6,field7,field8,field9, field10
val1 val2 val3 val5 val6 val7 val8 val9 val10

Re: Has anyone experienced values shifted to the wrong field when displaying a KV Store Lookup table in a dashboard?

codiceluna — Wed, 10 Apr 2019 20:56:21 GMT

It's fixed. I can't take the credit. A coworker found the issue.

I removed this line in the CSS

highlight td:nth-child(27){display: none}

Re: Has anyone experienced values shifted to the wrong field when displaying a KV Store Lookup table in a dashboard?

woodcock — Thu, 11 Apr 2019 23:46:04 GMT

There is a bug in several versions of 7.* related to fields and table. @rich7177 discovered it was broken in 7.2.0 and 7.2.1 and was likely (never checked but they claimed so) fixed in 7.2.2, was tested fixed by him in 7.2.3. From support:

The bug was introduced due to a new format called srs being used in 7.2.0. As a temporary workaround, we can simply disable the new format. However, note that performance may degrade as we are reverting to pre-7.2.x functionality. To do this, you would edit limits.conf and specify results_serial_format to use "csv" under the [search] stanza.

results_serial_format = [csv|srs]
* The internal format used for storing serialized results on disk.
* Options:
* csv: Comma-separated values format
* srs: Splunk binary format
* Default: srs
* NOTE: Do not change unless instructed to do so by Splunk Support

To reproduce:

| makeresults | fields - _time | eval FieldA="Value A" | eval FieldB="Value B" | fields FieldA FieldA FieldA FieldB`

If broken, it returns FieldA=ValueA, FieldB=ValueA. If it's not broken, it returns FieldA=ValueA, FieldB=ValueB.

There is a similar bug discovered and reported by @rvaglid in 7.2.1 that is tracked by SPL-162308 and SPL-164718 and seemed to be caused by phased_execution_mode = singlethreaded in limits.conf.

Let us know either of these is your problem here (these may actually be the same thing; I am not sure).

Re: Has anyone experienced values shifted to the wrong field when displaying a KV Store Lookup table in a dashboard?

codiceluna — Sat, 13 Apr 2019 06:30:58 GMT

Thanks for the feedback! I'll keep this handy in case I run into something like this again. I really hope not. It was very unpleasant. What I was experiencing definitely seemed like a bug but turned out to be and issue in my CSS.