My ELK servers are located in Asia/Seoul timezone which is GMT+9:00. Elasticsearch creates indices on a daily basis, but the indices are created at 9AM (instead of 12AM) due to timezone difference.
I know Kibana corrects the timezone with browser's timzone but I need to run Curator at 1AM every day to move indices from hot to warm nodes. currently Curator is unable to execute allocation at 1AM because Logstash/Elasticsearch use 'yesterday' index until 9AM.
How can i create index with different timezone other than UTC?
To do this, should I change @timestamp? or is there anything i should do in Elasticsearch "_template"?
If I change @timestamp with 'Asiz/Seoul' timezone (maybe using Ruby?), below output for elasticsearch "YYMMdd" will work properly and index will be created at 12AM (probably 12:00:01)?
To do this with cronjob, i need to run cronjob (for curator) after 9AM after ‘today’ new indices are created. But there is too many traffics already. That’s why i wated to run cronjob at 1AM during not busy hours.
Sounds like a use case for rollover indices instead, then. Rollover the indices at midnight in your time zone, and migrate them to the warm node. There's no real need to keep one day's data in a single index, is there? The index patterns in Kibana don't see day boundaries.
I guess below options are potentials with limited disk storage (hot nodes) situation.
#1. add disk space and configure Elasticsearch config file to use new disk. #2. indices creation period change so Logstash will call Elasticsearch to create HOURLY based indices. then, curator will run every 12hours to move previous 12hours indices from hot to warm node.
I am also considering to do above #1 option, but it can be happened sometime next month. When it is done, we can store more than 1day indices in hot node, but currently hot node disk size is not enough so as I posted here I would store only 1day 'today' indices.
If I will go for above #2 option, is there anything I need to change/configure on Elasticsearch side? I guess not but wanted to confirm.
Go with the rollover index API as Aaron suggested, as this is very flexible and allows you to cut indices at any point in time. Switching to hourly indices seems like a bad idea as having lots of small indices/shards can be very inefficient.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.