# Metricbeat index lifecycle policy (ILM) not rolling over **URL:** \ **Category:** Elasticsearch\ **Tags:** ilm-index-lifecycle-management\ **Created:** [November 8, 2019, 8:55pm UTC](https://discuss.elastic.co/t/metricbeat-index-lifecycle-policy-ilm-not-rolling-over/207173 "2019-11-08T20:55:18Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [November 8, 2019, 8:55pm UTC](https://discuss.elastic.co/t/metricbeat-index-lifecycle-policy-ilm-not-rolling-over/207173/1 "2019-11-08T20:55:19Z")
ECE 2.3 ES and Kibana v7.3.0 I'm having trouble getting an index lifecycle policy to rollover. I currently have an index called metricbeat-7.0.0-2019.10.21-000001 that has an alias of metricbeat-7.0.0. The index has three primary shards and 1 replica. I added a Index Lifecycle Policy calle metricbeat-7.0.0 to the metricbeat-7.0.0-2019.10.21-000001 index that has a maximum index size of 150GB, max docs of 2000000000 and a maximum age of 30 days. If I understand the shard to max index size ratio correctly you can multiply your desired index size by the amount of primary shards. In this example that would be 3 times 50GB = 150Gb. As of right now the index is way past 150GB and still has not rolled over. Details below. ```auto GET _cat/aliases/metricbeat* metricbeat-7.0.0 metricbeat-7.0.0-2019.10.21-000001 - - - ``` ```auto GET /_template/metricbeat-7.0.0 { "metricbeat-7.0.0" : { "order" : 1, "index_patterns" : [ "metricbeat-7.0.0-*" ], "settings" : { "index" : { "lifecycle" : { "name" : "metricbeat-7.0.0", "rollover_alias" : "metricbeat-7.0.0" }, "codec" : "best_compression", "mapping" : { "total_fields" : { "limit" : "10000" } }, "refresh_interval" : "5s", "number_of_shards" : "3", "query" : { ..... *DELETED THIS INFO }, "aliases" : { } } } ``` ```auto GET _ilm/policy { "metricbeat-7.0.0" : { "version" : 5, "modified_date" : "2019-10-29T14:02:00.819Z", "policy" : { "phases" : { "hot" : { "min_age" : "0ms", "actions" : { "rollover" : { "max_size" : "150gb", "max_age" : "30d", "max_docs" : 2000000000 }, "set_priority" : { "priority" : 100 } } }, "delete" : { "min_age" : "93d", "actions" : { "delete" : { } } } } } }, "watch-history-ilm-policy" : { "version" : 1, "modified_date" : "2019-09-11T19:40:10.125Z", "policy" : { "phases" : { "delete" : { "min_age" : "7d", "actions" : { "delete" : { } } } } } } ``` ```auto GET _ilm/status { "operation_mode" : "RUNNING" } ``` ```auto GET _cluster/settings { "persistent" : { "action" : { "auto_create_index" : "true" }, "cluster" : { "routing" : { "allocation" : { "disk" : { "threshold_enabled" : "true" } } }, "indices" : { "close" : { "enable" : "false" } } }, "xpack" : { "monitoring" : { "collection" : { "enabled" : "true" } } } }, "transient" : { "action" : { "auto_create_index" : "true" }, "cluster" : { "routing" : { "allocation" : { "disk" : { "threshold_enabled" : "true" }, "exclude" : { "_name" : "no_instances_excluded" }, "awareness" : { "attributes" : "region,availability_zone,logical_availability_zone" }, "enable" : "all" } }, "indices" : { "close" : { "enable" : "false" } } } } } ``` ---
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [November 19, 2019, 3:37pm UTC](https://discuss.elastic.co/t/metricbeat-index-lifecycle-policy-ilm-not-rolling-over/207173/2 "2019-11-19T15:37:56Z")
Bump 🙂 So this did eventually roll over but at 300GB. Not exactly sure why that is but any insight would be appreciated. ---
**Author:** ![Ryan\_Downey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryan_downey/32/35987_2.png) [@Ryan\_Downey](https://discuss.elastic.co/u/Ryan_Downey)\ **Post date:** [November 21, 2019, 2:31pm UTC](https://discuss.elastic.co/t/metricbeat-index-lifecycle-policy-ilm-not-rolling-over/207173/3 "2019-11-21T14:31:30Z")
This has been solved. Check out your ILM policy first to make sure everything is set correctly with ```auto GET /_ilm/explain ``` Check your indices to make sure everything looks good there. ```auto GET _cat/indices/metricbeat-7.0.0* ``` Then check to see that the indices in question are the right size with ```auto GET _cat/shards/metricbeat-7.0.0* ``` In our environment we need to check these indices and their size: ```auto metricbeat-7.0.0-2019.11.10-000002 1 r STARTED 284644728 50gb 10.108.53.124 instance-0000000013 metricbeat-7.0.0-2019.11.10-000002 1 p STARTED 284644728 50gb 10.108.53.126 instance-0000000012 metricbeat-7.0.0-2019.11.10-000002 2 p STARTED 284664165 50gb 10.108.53.125 instance-0000000014 metricbeat-7.0.0-2019.11.10-000002 2 r STARTED 284664165 50gb 10.108.53.126 instance-0000000012 metricbeat-7.0.0-2019.11.10-000002 0 r STARTED 284642933 50gb 10.108.53.125 instance-0000000014 metricbeat-7.0.0-2019.11.10-000002 0 p STARTED 284642933 50gb 10.108.53.124 instance-0000000013 ``` Everything was setup correctly I just misunderstood how ILM was implemented as the 150GB rollover size that I had selected is based off of 3 primary shards at 50GB each. The Storage Size displayed in Kibana includes primary and replica shards so the policy did not seem like it was triggering at the right time but it was. Our metricbeat indices are setup with 1 replica shard so 3 primaries at 50GB = 150GB and 3 replicas at 50GB = 150GB and therefore you end up with 300GB displayed in Kibana as the Storage Size. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 19, 2019, 2:41pm UTC](https://discuss.elastic.co/t/metricbeat-index-lifecycle-policy-ilm-not-rolling-over/207173/4 "2019-12-19T14:41:14Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.