Kibana error displaying numbers in Discover


I have applied the suggested technique to prevent from duplicates creation in the Logstash output plugin for Elasticsearch, as described here:

Basically I associate to the _id field, the id field provided by the application generating the messages (id is the timestamp at nanotime):

output {
elasticsearch {
hosts => "host_IP"
document_id => "%{[id]}"

Therefore I would expect to see in Kibana the same value for _id and id.

This correct association happens in the most of the cases but sometimes I notice that, in the Kibana Discover view, the _id field differs by 1 respect to the id field. Here is an example (in the Kibana index pattern _id is type string and id is type number):

_id= 11335773562862155 (correct value)
id= 11,335,773,562,862,156 (wrong value)

Please note that I write correct or wrong above with respect to the original message being published to Kafka, before hitting the ELK stack.

Moreover if I search for this specific document filtering by id, I obtain a result only if I search for
id = 11335773562862155. This induce me to think that the association from the Logstash plugin works as expected but somehow the value is not properly displayed by the Kibana interface.

Does anyone have an idea about the origin of this incorrect display in the Kibana Discover view? Is it some Javascript casting issue?

Hi, this is a JavaScript issue with the size of your number, which exceeds the maximum safe integer value.


Recommend to change the mappings for id field to string to make this field work with Kibana, or you can try changing the field format to String in Management > Index Patterns.

Thanks for the quick reply jen-huang.

I have tried to change the field format to String in the Management view but it doesn't solve the problem.

I will consider if changing the id field mapping is necessary. At the moment this inconvenient only affect the display in Kibana for a field which is not so important to be visually inspected. The major requirement is to avoid duplicates and have the correct information stored in Elasticsearch for the sake of data quality.

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