# Logstash writing to older index
**URL:** https://discuss.elastic.co/t/logstash-writing-to-older-index/369754
**Category:** Logstash
**Created:** [October 29, 2024, 4:16pm UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754 "2024-10-29T16:16:27Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@devops\_training](https://discuss.elastic.co/u/devops_training)
#### Post date: [October 29, 2024, 4:16pm UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754/1 "2024-10-29T16:16:27Z")
Below is the error message from logstash.
The Elasticsearch is designed with hot, warm and cold nodes. Index is created on daily basis.
[2024-10-29T11:14:22,632][INFO][logstash.outputs.elasticsearch][main][1dde6b9e90686623464913a83aa66d3d68284a23f9523852fe779664b16dd7a1] Retrying failed action {:status=\>429, :action=\>["index", {:\_id=\>"717162ethbnbxmansksdjioqdjalmx,amaksdjaknd11", :\_index=\>"western2-2024.10.18", :routing=\>nil}, {"container"=\>{"name"=\>"service", "id"=\>"ape-service-1.2.500-54c4788d55-lnmwb"}, "path"=\>"/nfs/logs/ape2/nfs.service+ape-service-1.2.500-54c4788d55-lnmwb", "type"=\>"ape2-stats", "labels"=\>{"direction"=\>"read", "eventglobalid"=\>"unknown", "apeeventid"=\>19134, "failed"=\>"no", "apeseverity"=\>"MAJOR", "EventClassID"=\>"EventStats", "autoid"=\>29928, "autoguid"=\>"c174f5c8-6a75-44f4-8e57-0de13a180581", "Severity"=\>"Medium", "tenant"=\>"12345jajnammm", "source"=\>"["dxl://kafka-prod-usw-1a-0.kafka-dev-heeadless.svc.cluster.local:9009,kafka-prod-usw-1a-1.kafka-dev-heeadless.svc.cluster.local:9009,kafka-prod-usw-1a-2.kafka-dev-heeadless.svc.cluster.local:9009/ape.incident.raw/group0/0"]", "Description"=\>"Statistical Information Per Event"}, "@version"=\>"1", "log"=\>{"level"=\>"Information"}, "host"=\>"logstash-service-49fk8", "fingerprint"=\>"717162ethbnbxmansksdjioqdjalmx,amaksdjaknd11", "@timestamp"=\>2024-10-18T00:00:50.061Z}], :error=\>{"type"=\>"cluster\_block\_exception", "reason"=\>"index [western2-2024.10.18] blocked by: [TOO\_MANY\_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];"}}
Below is the index name western2-2024.10.18
why is logstash trying to write to older index western2-2024.10.18. How does it know that it should write events index.
please help.
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [October 29, 2024, 4:38pm UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754/2 "2024-10-29T16:38:28Z")
> [@devops\_training](#):
>
> why is logstash trying to write to older index western2-2024.10.18. How does it know that it should write events index.
What does your logstash output looks like?
You said that index is created on a daily basis, so your output is probably something like this: `western2-%{+YYYY.MM.dd}`
So Logstash will use the value of the `@timestamp` field to populate the `YYYY.MM.dd` string.
The value of `@timestamp` field in the event you shared is `2024-10-18T00:00:50.061Z`, so tihs is expected.
---
### Author:  [@devops\_training](https://discuss.elastic.co/u/devops_training)
#### Post date: [October 30, 2024, 4:38am UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754/3 "2024-10-30T04:38:36Z")
Thanks @leandrojmp. But the day this event was happening is 10/29/2024. [2024-10-29T11:14:22,632][INFO][logstash.outputs.elasticsearch][main] so why is this happening on 29th?
---
### Author:  [@Rios](https://discuss.elastic.co/u/Rios)
#### Post date: [October 30, 2024, 6:02am UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754/4 "2024-10-30T06:02:06Z")
> [@devops\_training](#):
>
> disk usage exceeded flood-stage watermark, index has read-only-allow-delete block
There was not enough disk space on ES side at the moment. As you know ILM automatically manage indices, which means it moves data/shards between hot, warm,cold. LS doesn't have anything with this.
`GET _cluster/settings` will provide values:
```auto
cluster.routing.allocation.disk.watermark.low: (Default 85%)
cluster.routing.allocation.disk.watermark.high: (Default 90%)
cluster.routing.allocation.disk.watermark.flood_stage: (Default 95%)
```
It's possible that you didn't have enough disk space at the moment, which is the reason why LS recorded the error. Then ILM policy move/delete data from the disk and LS continue to work.
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [October 30, 2024, 12:40pm UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754/5 "2024-10-30T12:40:30Z")
> [@devops\_training](#):
>
> But the day this event was happening is 10/29/2024. [2024-10-29T11:14:22,632][INFO][logstash.outputs.elasticsearch][main] so why is this happening on 29th?
This is the date that logstash processed the event.
If you have a `date` filter that will parse some field from your event and your event has an older date, then this is expected.
Also, your input seems to be a `file` input reading from some `nfs` share, so this could mean that Logstash read some old files.
---
### Author:  [@rugenl](https://discuss.elastic.co/u/rugenl)
#### Post date: [October 30, 2024, 10:59pm UTC](https://discuss.elastic.co/t/logstash-writing-to-older-index/369754/6 "2024-10-30T22:59:57Z")
This style of index naming can cause problems, I've had windows systems get configured without ignore\_older and load years of indices.
Use data streams for time series data, @timestamp will still be old, but only the current index will be written. FYI, nobody ever finds this data, they never look for old data. I have some filters for network devices that always log 1980's date at reboot, until they update their time, I just have logic that says "older than 3 days, nope, set @timestamp to now.".