# Type Mismatch between Ingest Pipeline and Kibana **URL:** \ **Category:** Elasticsearch\ **Created:** [February 16, 2018, 8:22am UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119 "2018-02-16T08:22:26Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![SIVA\_S2018](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/siva_s2018/32/46322_2.png) [@SIVA\_S2018](https://discuss.elastic.co/u/SIVA_S2018)\ **Post date:** [February 16, 2018, 8:22am UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/1 "2018-02-16T08:22:26Z")
Hello Team, We are facing an issue with Elastic Stack and Kabana type mismatch. Kabana is not picking up type as NUMBER rather shows them as string. Here is what we've tried, - Initially used ingest pipeline node grok processor to parse data from CSV file as type "DATA", the index type on Kabana is being shown as Type String. - Changed the values to Type NUMBER (for values which are like 1.0, 0.003 ), the data is not being parsed at all. - Now changed the value to BASE64 , ingest processor node, parses the data, however Kabana still shows them as type string. Tried with new ingest pipeline, new name for the tags, still the values in Kabana are shown as string. Any help / suggestion please on why sometimes ingest pipeline grok processor are not picking up NUMBER and then Kabana not showing the type as NUMBER.. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [February 16, 2018, 8:39am UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/2 "2018-02-16T08:39:12Z")
Run ```auto GET yourindexname/_mapping ``` And check what is the mapping for that field. If `text`, then that explains and you need to adapt your mapping. ---
**Author:** ![SIVA\_S2018](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/siva_s2018/32/46322_2.png) [@SIVA\_S2018](https://discuss.elastic.co/u/SIVA_S2018)\ **Post date:** [February 16, 2018, 9:15am UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/3 "2018-02-16T09:15:11Z")
Thanks Dave.. Looking at the mapping , here is what I have, "L75Pc": { "type": "keyword", "ignore\_above": 1024 }, and so on for all the fields.. Grok processor has it defined as BASE16FLOAT. Is there way we can change the field type..? ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [February 16, 2018, 9:34am UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/4 "2018-02-16T09:34:49Z")
You need to provide your own mapping and reindex. ---
**Author:** ![SIVA\_S2018](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/siva_s2018/32/46322_2.png) [@SIVA\_S2018](https://discuss.elastic.co/u/SIVA_S2018)\ **Post date:** [February 16, 2018, 3:46pm UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/5 "2018-02-16T15:46:00Z")
Thanks Dave.. At which level, the reindex needs to be done. Is it withing ingest grok processor ? Is Kibana picking up the default data type (which is string), we tried deleting the index and re-creating, however still we get the data type as string. Is there any pointers or example you can share. Any pointers to specific document will also be helpful. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [February 16, 2018, 5:01pm UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/6 "2018-02-16T17:01:13Z")
Basically do: ```auto DELETE myindex PUT myindex { "mappings": { "doc": { "properties": { "foo": { "type": "integer" } } } } } PUT myindex/doc/1 { "foo": 1 } ``` That should work. Once you understand what I wrote as an example, apply this to your documents and generate a correct mapping. Then index your source (whatever it is) in this index `myindex` or use the reindex API to read from your bad index and index in `myindex`. Note that if you have been using the correct type in JSON, that would be even better. IE: instead of indexing: ```auto { "foo": "1" } ``` Index ```auto { "foo": 1 } ``` ---
**Author:** ![SIVA\_S2018](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/siva_s2018/32/46322_2.png) [@SIVA\_S2018](https://discuss.elastic.co/u/SIVA_S2018)\ **Post date:** [February 19, 2018, 3:48pm UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/7 "2018-02-19T15:48:50Z")
Thanks Dave. We have now removed the indexes completely and added the following ingest grok pattern, which works fine as long as data is available... { "description": " test ingest pipeline data", "processors": [ { "grok": { "field": "message", "patterns": [ "^%{Data:abc.timestamp}\,?%{DATA:Count:int}?, \?%{DATA:Average:float}?" ] } } ] However, whenever there is no data, it throws an ingest error as empty string. Do you know if there is better way to specify ignore empty strings (other than the '?'). Also is there way we can turn on debug for ingest pipelines. Thanks, ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [February 19, 2018, 4:29pm UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/8 "2018-02-19T16:29:07Z")
Please format your code. > Do you know if there is better way to specify ignore empty strings (other than the '?'). Read: [Handling failures in pipelines | Elasticsearch Guide [master] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/master/handling-failure-in-pipelines.html) > Also is there way we can turn on debug for ingest pipelines. This might help: [Simulate pipeline API | Elasticsearch Guide [master] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/master/simulate-pipeline-api.html#ingest-verbose-param) ---
**Author:** ![SIVA\_S2018](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/siva_s2018/32/46322_2.png) [@SIVA\_S2018](https://discuss.elastic.co/u/SIVA_S2018)\ **Post date:** [February 21, 2018, 12:24pm UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/9 "2018-02-21T12:24:16Z")
Thanks Dave, The latest issue seems more of a specific problem, As it stands we now have a Grok ingest pipeline, { "description": "Pipeline for parsing log", "processors": [ { "grok": { "field": "message", "patterns": ["^%{DATA:abc.timestamp}\|%{DATA:abc.org}:%{DATA:abc.xycr}:%{INT:abc.counter}\|%{DATA:Try}\|%{DATA:ID}?$” ] } { "convert": { "field": "Try", "type": "float", "ignore\_missing": true } }, { "convert": { "field": "ID", "type": "integer", "ignore\_missing": true } The issue we are now facing is on the Kibana front where the Variable Try and ID are shown as Text rather than Numbers. We did multiple testing after clearing up the indices, and noticed that whenever the values are present, then they are treated as Numbers in Kibana and if the values are not present, I think it is being treated as Null String and in Kibana it is represented as Text. Is there way these variable can always be treated as numbers. In the GROK processor, we did try representing them as NUMBER rather than DATA, however it throws an exception, which I think NUMBER always expect some values in it. We are running ELK Version 5.6.0. Do you know if there is way around it..? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [March 21, 2018, 12:24pm UTC](https://discuss.elastic.co/t/type-mismatch-between-ingest-pipeline-and-kibana/120119/10 "2018-03-21T12:24:16Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.