# Bad JSON interpretation on Kibana Discover view

**URL:** <https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135>\
**Category:** Kibana\
**Created:** [March 13, 2019, 11:32am UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135 "2019-03-13T11:32:30Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mikolaj\_Solik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mikolaj_solik/32/41887_2.png) [@Mikolaj\_Solik](https://discuss.elastic.co/u/Mikolaj_Solik)\
**Post date:** [March 13, 2019, 11:32am UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135/1 "2019-03-13T11:32:30Z")

</div>

Hello all, I have a question, if someone know what can be issue, when on Discovery view I get a JSON on each row, insted of separated rows, eg.:

I get this:  
? beat { "name": "hostname.domain", "hostname": "hostname.domain", "version": "6.4.3" }

But want to get this, on separate rows:  
t beat.name hostname.domain  
t beat.hostname hostname.domain  
t beat.version 6.4.3

It started to behave like that from unknown reason. I suspect, that this can be related with Logstash upgrade, but unable to find how to allign this all to new version, or maybe better to downgrade this? On some indexes I get a proper split values and for some I get JSON.

Kibana version:  
kibana-6.4.1-1.x86\_64

Beats:  
execbeat-3.3.0-1.x86\_64  
metricbeat-6.4.0-1.x86\_64  
heartbeat-elastic-6.4.3-1.x86\_64  
filebeat-6.4.0-1.x86\_64

Logstash:  
logstash-6.4.3-1.noarch \<- upgraded from logstash-6.4.1-1.noarch

Elasticsearch:  
elasticsearch-6.4.1-1.noarch

Sample filter on Logstash:

```auto
filter {
    if [fields][idxtypefield] == "sal-metrics-logs-heartbeat" {
	if ([http][response][status_code]) {
             mutate {
                replace => { "[monitor][status]" => "up" }
             }
	}
   }
}

```

Input is from Heartbeat and nothing was changed since Logstash upgrade. Any ideas?

---

<div class="post-metadata">

**Author:** ![joshdover](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joshdover/32/42020_2.png) [@joshdover](https://discuss.elastic.co/u/joshdover)\
**Post date:** [March 14, 2019, 8:46pm UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135/2 "2019-03-14T20:46:06Z")

</div>

Have a few questions that might help me assist:

- If you compare one index that is working correctly and one that isn't, do the mappings and documents look the same?
- Are these indices using the same index pattern in Kibana? If not, have you tried refreshing the index pattern's columns? (you can do this under Management \> Kibana \> Index Patterns, selecting the one you want to refresh and clicking refresh icon in the top right).
- Can you provide any screenshots so I have better understanding of what you're seeing?

---

<div class="post-metadata">

**Author:** ![Mikolaj\_Solik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mikolaj_solik/32/41887_2.png) [@Mikolaj\_Solik](https://discuss.elastic.co/u/Mikolaj_Solik)\
**Post date:** [March 15, 2019, 6:37am UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135/3 "2019-03-15T06:37:42Z")

</div>

Thank you for your respond joshdover 🙂

1. Comparing diferent index'es all have a good structure of JSON and for all is interpreted correct and for two that I found, bad. Eg. I have two index'es that comes from one pipeline on logstash and get on one splited correct and on second bad...both of them have exactly the same structure of JSON.

2. No, all use diffrent index pattern. I tried refresch index pattern. Eg.:

- Working fine with the same data structure: metrics-es\_monitoring-\*
- Broken: metrics-sales\_monitoring-\*

1. Sample screenshots below:  
**Index pattern:**  
 ![image](https://us1.discourse-cdn.com/elastic/original/3X/0/b/0b7f27b07bf0f3a7a0f5a6568f0ccf9a61753891.png)

**Discovery view:**

 ![discovery](https://us1.discourse-cdn.com/elastic/original/3X/9/8/98d70a9312abaad0cafbbdc59e0a2470dfc98f67.png)

**Other index, with the same structure of JSON:**

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/f/c/fc3332f77ee0312249a568fe58b3cd90318f7113.png)  
 ![discovery2](https://us1.discourse-cdn.com/elastic/original/3X/5/6/5671a9b177da792b000c980f7ca8b990ddd61ac9.png)

I tried to downgrade logstashes from 6.4.3-1 to 6.4.1-1, but this did not help. One wierd thing is, that I have Acceptance ENV that have same data as on PRD and I can see on ACC everything works fine...I have idea to upgrade all ELK Stack to 6.6 version, but first need to test this on ACC. Maybe elier someone figure out whats the issue. On all infra two big actions was performed eliear:

1. Reinstall all beats - But without Heartbeat, that is also broken, so this trail I think we can decline.
2. Upgrade Logstash - But I rollback this and this not help.

More details:

- I reinstalled all beats a couple days ago, but all beats was reinstalled in the same way as always and did not get any error. Also Heartbeat I did not reinstall and I have error on index related with this beat, so I suppose this is not beats fault.
- I restarted all ELK Infra, but not work..
- I compered a couple Lostash configs and all have the same structure comparing to this two not working
- I can not find any use full informations in logs on KIbana, Logstash or Elasticsearch...

I have suspecius, that this can be related with some BUG on Kibana, but not sure...

---

<div class="post-metadata">

**Author:** ![joshdover](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joshdover/32/42020_2.png) [@joshdover](https://discuss.elastic.co/u/joshdover)\
**Post date:** [March 15, 2019, 2:50pm UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135/4 "2019-03-15T14:50:45Z")

</div>

Based on your screenshots, it looks like the "bad" index does not have mappings for the `beat.name`, `beat.hostname`, and `beat.version` fields so Kibana is simply displaying the entire object. (Hint: this is what the little question mark symbol to the left of the fieldname (`beat`) means in Discover).

The reason that mapping is missing is because you're running a much older version of `execbeat` (3.3.0) against a newer version of Elasticsearch, however your other Beats are up to date, which does have that mapping.

We only officially support matching major versions, so I would recommend upgrading that execbeat to 6.4.1 to match your Elasticsearch version which should resolve the issue. Be sure to run `execbeat setup` after upgrading it to 6.4.1.

Cheers!

---

<div class="post-metadata">

**Author:** ![Mikolaj\_Solik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mikolaj_solik/32/41887_2.png) [@Mikolaj\_Solik](https://discuss.elastic.co/u/Mikolaj_Solik)\
**Post date:** [March 18, 2019, 10:27am UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135/5 "2019-03-18T10:27:38Z")

</div>

Thank you very much for support. I think this sound like good plan. We will work on this to upgrade all env and align to newest versions of Beats etc.

Thank you!

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [April 15, 2019, 10:27am UTC](https://discuss.elastic.co/t/bad-json-interpretation-on-kibana-discover-view/172135/6 "2019-04-15T10:27:38Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
