Since the name of index get the date information from the field @timestamp and you are getting the value for the @timestamp field from a field in your document, you need to check in the source file that filebeat is reading if you have old values for this field.
There is not in your Logstash pipeline that would do that, the issue is probably on your source file, not even in Filebeat.
From what you shared the value of the @timestamp field comes from the value of the ts field in your documents, so you may have events where this value is older than the current date.
@leandrojmp, I have checked the source file, it does not have any @timestamp field in it. Due to data privacy, it is not possible for me to provide the source file here.
But I still doubt on the Persistent queue, DO you have any idea, what is the behavior when logstash's output destination such as lumberjack is not available for sometime and logstash restarted due to some reason?
The persistent queue resides between the input and the filter block, if you have it enabled when logstash receives a message it will be put on this queue to be processed.
If an output has some issues the messages will start to accumulate in the persisted queue until it is full, when it is full logstash will stop to accept new messages until the output is back and it can start to drain the persisted queue.
When you restart logstash, it will start to process the persisted queue again.