# Failed to parse timestamp exception, (only) when using a new Elasticsearch index name

**URL:** <https://discuss.elastic.co/t/failed-to-parse-timestamp-exception-only-when-using-a-new-elasticsearch-index-name/126407>\
**Category:** Beats\
**Tags:** metricbeat\
**Created:** [April 2, 2018, 9:39am UTC](https://discuss.elastic.co/t/failed-to-parse-timestamp-exception-only-when-using-a-new-elasticsearch-index-name/126407 "2018-04-02T09:39:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrei.costache](https://avatars.discourse-cdn.com/v4/letter/a/0ea827/32.png) [@andrei.costache](https://discuss.elastic.co/u/andrei.costache)\
**Post date:** [April 2, 2018, 9:39am UTC](https://discuss.elastic.co/t/failed-to-parse-timestamp-exception-only-when-using-a-new-elasticsearch-index-name/126407/1 "2018-04-02T09:39:52Z")

</div>

Hi,

I am using Elasticsearch, Kibana and Metricbeat 6.1.1. I would like to use a different index name, for Metricbeat, than the default one. But I have problems as shortly follow:

1. When I start Metricbeat, with default preferences (index name, pattern etc.), I am able to record the data in Elasticsearch and inspect in Kibana without a problem. (the `metricbeat` index gets created correctly in Elasticsearch)
2. Then, in the _metricbeat.yml_ file, I simply changed the Elasticsearch `output.elasticsearch.index` to something custom, along with the indicated `setup.template.name` and `setup.template.pattern` accordingly:

> output.elasticsearch.index: "my-index-name-%{[beat.version]}-%{+yyyy.MM.dd}"  
> setup.template.name: "my-index-name"  
> setup.template.pattern: "my-index-name-\*"

1. In this case, when Metricbeat starts up, I get the following exception:

> failed to execute bulk item (index) BulkShardRequest [[my-index-name][0]] containing [index....] ...  
> ... org.elasticsearch.index.mapper.MapperParsingException: failed to parse [@timestamp] ...  
> ... Caused by: java.lang.IllegalArgumentException: Invalid format: "2018-04-02T07:24:39.162Z"...

1. If I comment-out the custom `output.elasticsearch.index` setting, then all is fine again and the default `metricbeat` index is created without problem.

I do not understand why, without modifying any field mappings or other settings, it does not work for  
my custom metricbeat index, yet works if I comment the setting out.

I have searched the reference(s) and forum posts for a possible answer. But I fail to understand what I am missing (or doing wrong).  
I apologize in advance if the question already has an answer which I failed to find.

Thank you in advance!  
Andrei

---

<div class="post-metadata">

**Author:** ![andrei.costache](https://avatars.discourse-cdn.com/v4/letter/a/0ea827/32.png) [@andrei.costache](https://discuss.elastic.co/u/andrei.costache)\
**Post date:** [April 3, 2018, 12:54pm UTC](https://discuss.elastic.co/t/failed-to-parse-timestamp-exception-only-when-using-a-new-elasticsearch-index-name/126407/2 "2018-04-03T12:54:49Z")

</div>

Hi,

I managed to find the problem, after searching and comparing type mapping specifications in my application. (I am not that experienced with the ELK stack yet.)

Unfortunately, it appears I had (have) an index template in code, that specified a different `@timestamp` format. The template was specified something like

> { "template": "my-\*",....  
> "mappings": ... "properties": "@timestamp": { "type": "date", "format": "epoch\_millis"}  
> .. }

and this caused the trouble with `my-index-name` index.

Anyway, hope this answer might help other beginners as myself...

Best regards,  
Andrei.

---

<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:** [May 1, 2018, 12:55pm UTC](https://discuss.elastic.co/t/failed-to-parse-timestamp-exception-only-when-using-a-new-elasticsearch-index-name/126407/3 "2018-05-01T12:55:24Z")

</div>

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