# Elastic Search Unclear Mapper Parsing Exception

**URL:** <https://discuss.elastic.co/t/elastic-search-unclear-mapper-parsing-exception/339108>\
**Category:** Elasticsearch\
**Created:** [July 24, 2023, 1:56pm UTC](https://discuss.elastic.co/t/elastic-search-unclear-mapper-parsing-exception/339108 "2023-07-24T13:56:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![optimaX](https://avatars.discourse-cdn.com/v4/letter/o/54ee81/32.png) [@optimaX](https://discuss.elastic.co/u/optimaX)\
**Post date:** [July 24, 2023, 1:56pm UTC](https://discuss.elastic.co/t/elastic-search-unclear-mapper-parsing-exception/339108/1 "2023-07-24T13:56:42Z")

</div>

Incident:  
I'm currently working on a log pipeline which forwards the logs from an API - of our Anti-Virus solution - to Graylog and therefore Elasticsearch behind that. However, I encountered a very strange mapper-parsing exception (which means that Elasticsearch couldn't parse the input to the expected datatype). I'll attach two examples of the same problem right here:

`ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse field [file_attribute_ids] of type [long] in document with id 'e34ccd28-2a22-11ee-90d7-0242ac100112'. Preview of field's value: '[5, 12]']]; nested: ElasticsearchException[Elasticsearch exception [type=illegal_argument_exception, reason=For input string: "[5, 12]"]];`

`ElasticsearchException[Elasticsearch exception [type=mapper_parsing_exception, reason=failed to parse field [connection_src_port] of type [long] in document with id 'e1582915-2a22-11ee-90d7-0242ac100112'. Preview of field's value: '63318, 63320']]; nested: ElasticsearchException[Elasticsearch exception [type=illegal_argument_exception, reason=For input string: "63318, 63320"]];`

So somehow Elasticsearch has a problem parsing these lists to longs. As far as I understood, Elasticsearch also supports multiple values in a field from the ground up, so this list of longs shouldn't be a problem at all ...

Environment:

- OS Information: Linux 5.15.0-73-generic
- Package Version: Graylog 5.1.1+ef1b993 on graylog (Eclipse Adoptium 17.0.7)

What steps have you already taken to try and solve the problem?

- Tried to parse every value in both fields as explicit integers. No success.
- Transformed the datatype of these fields to String. Works until now without any more exceptions.

How can somebody help?  
Please clarify whether this is a bug by Elasticsearch / Graylog or I'm just using these products in an inappropriate way. Thank you very much for your time!

---

<div class="post-metadata">

**Author:** ![Opster\_support](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/opster_support/32/56687_2.png) [@Opster\_support](https://discuss.elastic.co/u/Opster_support)\
**Post date:** [July 24, 2023, 5:48pm UTC](https://discuss.elastic.co/t/elastic-search-unclear-mapper-parsing-exception/339108/2 "2023-07-24T17:48:17Z")

</div>

The issue you're encountering is not a bug in Elasticsearch or Graylog, but rather a mismatch between the data type defined in your Elasticsearch mapping and the actual data you're trying to index.

In Elasticsearch, a field can indeed hold multiple values, but the entire array needs to be of the same data type. In your case, the fields `file_attribute_ids` and `connection_src_port` are defined as `long` in your mapping, but you're trying to index arrays of longs (e.g., `[5, 12]` and `63318, 63320`), which is causing the mapper parsing exception.

To fix this issue, you need to ensure that the data you're indexing matches the data type defined in your Elasticsearch mapping. If you expect these fields to contain arrays of longs, you should adjust your log pipeline to transform these fields into arrays of longs before indexing the data into Elasticsearch.

Here's a general approach to fix this issue:

1. Adjust your log pipeline: Modify your log pipeline to transform the `file_attribute_ids` and `connection_src_port` fields into arrays of longs before forwarding the logs to Elasticsearch. This could involve parsing the fields as strings, splitting the strings into arrays, and then converting each element in the arrays to a long.

2. Update your Elasticsearch mapping: If you have control over the Elasticsearch mapping, you could also consider updating the mapping to expect arrays of longs for these fields. However, this would require reindexing your existing data.

3. Use a script to transform the data: If you can't adjust your log pipeline or update your Elasticsearch mapping, you could consider using an ingest node with a script processor in Elasticsearch to transform the data as it's being indexed. The script would need to parse the fields as strings, split the strings into arrays, and then convert each element in the arrays to a long.

Please note that the specific steps to implement these solutions would depend on the details of your log pipeline and your Elasticsearch setup. If you need more detailed instructions, please provide more information about your log pipeline and your Elasticsearch mapping.

OpsGPT helped with part of this answer 😀

---

<div class="post-metadata">

**Author:** ![optimaX](https://avatars.discourse-cdn.com/v4/letter/o/54ee81/32.png) [@optimaX](https://discuss.elastic.co/u/optimaX)\
**Post date:** [July 25, 2023, 9:25am UTC](https://discuss.elastic.co/t/elastic-search-unclear-mapper-parsing-exception/339108/3 "2023-07-25T09:25:30Z")

</div>

Dear Opster\_support,

Thank you very much for this rapid and helpful reply! Approach 1 instantly fixed my issues and you provided this to me in no time - I would give 5 of 5 stars for this experience.

Have a great week!

---

<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:** [August 22, 2023, 9:25am UTC](https://discuss.elastic.co/t/elastic-search-unclear-mapper-parsing-exception/339108/4 "2023-08-22T09:25:59Z")

</div>

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