Dashboards & Visualizations

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

codiceluna
Engager

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.

Tags (1)
0 Karma
1 Solution

woodcock
Esteemed Legend

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).

View solution in original post

0 Karma

woodcock
Esteemed Legend

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).

0 Karma

codiceluna
Engager

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.

0 Karma

codiceluna
Engager

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

0 Karma

codiceluna
Engager

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}

0 Karma
Get Updates on the Splunk Community!

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...

New in Observability Cloud - Explicit Bucket Histograms

Splunk introduces native support for histograms as a metric data type within Observability Cloud with Explicit ...