Phases allowed: warm, cold.

The Allocate action allows you to specify which nodes are allowed to host the shards of the index and set the number of replicas. Behind the scenes, it is modifying the index settings for shard filtering and/or replica counts. When updating the number of replicas, configuring allocation rules is optional. When configuring allocation rules, setting number of replicas is optional. Although this action can be treated as two separate index settings updates, both can be configured at once.

Read more about index replicas here. Read more about shard allocation filtering in the Shard allocation filtering documentation.

If number_of_replicas is not configured, then at least one of include, exclude, and require is required. An empty Allocate Action with no configuration is invalid.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "allocate" : {
            "number_of_replicas" : 2
          }
        }
      }
    }
  }
}

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "allocate" : {
            "include" : {
              "box_type": "hot,warm"
            }
          }
        }
      }
    }
  }
}

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "allocate" : {
            "number_of_replicas": 1,
            "require" : {
              "box_type": "cold"
            }
        }
        }
      }
    }
  }
}

Phases allowed: delete.

The Delete Action does just that, it deletes the index.

This action does not have any options associated with it.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "delete": {
        "actions": {
          "delete" : { }
        }
      }
    }
  }
}

Phases allowed: warm.

Index will be be made read-only when this action is run (see: index.blocks.write)

The Force Merge Action force merges the index into at most a specific number of segments.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "forcemerge" : {
            "max_num_segments": 1
          }
        }
      }
    }
  }
}

Phases allowed: cold.

This action will freeze the index by calling the Freeze Index API.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "cold": {
        "actions": {
          "freeze" : { }
        }
      }
    }
  }
}

Freezing an index will close the index and reopen it within the same API call.
This causes primaries to not be allocated for a short amount of time and
causes the cluster to go red until the primaries are allocated again.
This limitation might be removed in the future.

Phases allowed: warm.

This action will set the index to be read-only (see: index.blocks.write)

This action does not have any options associated with it.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "readonly" : { }
        }
      }
    }
  }
}

Phases allowed: hot.

index format must match pattern ^.*-\\d+$, for example (logs-000001).

The managed index must set index.lifecycle.rollover_alias as the alias to rollover. The index must also be the write index for the alias.

If a policy using the Rollover action is used on a follower index, policy execution will wait until the leader index rolls over (or has otherwise been marked as complete), then convert the follower index into a regular index as if the Unfollow action had been used instead of rolling over.

For example, if an index to be managed has an alias my_data. The managed index "my_index" must be the write index for the alias. For more information, read Write Index Alias Behavior.

PUT my_index
{
  "settings": {
    "index.lifecycle.name": "my_policy",
    "index.lifecycle.rollover_alias": "my_data"
  },
  "aliases": {
    "my_data": {
      "is_write_index": true
    }
  }
}

The Rollover Action rolls an alias over to a new index when the existing index meets one of the rollover conditions.

At least one of max_size, max_docs, max_age or any combinations of the three are required to be specified.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_size": "100GB"
          }
        }
      }
    }
  }
}

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_docs": 100000000
          }
        }
      }
    }
  }
}

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_age": "7d"
          }
        }
      }
    }
  }
}

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_age": "7d",
            "max_size": "100GB"
          }
        }
      }
    }
  }
}

PUT /_ilm/policy/rollover_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50G"
          }
        }
      },
      "delete": {
        "min_age": "1d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Phases allowed: hot, warm, cold.

This action sets the index priority on the index as soon as the policy enters the hot, warm, or cold phase. Indices with a higher priority will be recovered before indices with lower priorities following a node restart. Generally, indexes in the hot phase should have the highest value and indexes in the cold phase should have the lowest values. For example: 100 for the hot phase, 50 for the warm phase, and 0 for the cold phase. Indicies that don’t set this value have an implicit default priority of 1.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "set_priority" : {
            "priority": 50
          }
        }
      }
    }
  }
}

Index will be be made read-only when this action is run (see: index.blocks.write)

If a policy using the Shrink action is used on a follower index, policy execution will wait until the leader index rolls over (or has otherwise been marked as complete), then convert the follower index into a regular index as if the Unfollow action had been used before shrink is applied, as shrink cannot be safely applied to follower indices.

This action shrinks an existing index into a new index with fewer primary shards. It calls the Shrink API to shrink the index. Since allocating all the primary shards of the index to one node is a prerequisite, this action will first allocate the primary shards to a valid node. After shrinking, it will swap aliases pointing to the original index into the new shrunken index. The new index will also have a new name: "shrink-<origin-index-name>". So if the original index was called "logs", then the new index will be named "shrink-logs".

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "shrink" : {
            "number_of_shards": 1
          }
        }
      }
    }
  }
}

This action may be used explicitly, as shown below, but this action is also run before the Rollover action and the Shrink action as described in the documentation for those actions.

This action turns a ccr follower index into a regular index. This can be desired when moving follower indices into the next phase. Also certain actions like shrink and rollover can then be performed safely on follower indices.

This action will wait until is it safe to convert a follower index into a regular index. In particular, the following conditions must be met:

If the unfollow action encounters a follower index then the following operations will be performed on it:

The unfollow action does not have any options and if it encounters a non follower index, then the unfollow action leaves that index untouched and lets the next action operate on this index.

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "unfollow" : {}
        }
      }
    }
  }
}