Skip to main content
Version: 3.2

Policies

Description

Policies are index management configurations that describe:

  • the states an index can be in, representing stages of its lifecycle (e.g., hot, warm, delete, etc.)
  • the actions to be performed on indexes in a given state (e.g., relocating to cold storage nodes or deleting the index)
  • the conditions that must be met for an index to transition from one state to another. For example, if the index age exceeds eight weeks, it should transition to a state where a delete action is defined

In other words, a policy defines the states an index can be in, the actions that need to be performed in each state, and the conditions that must be met to transition from one state to another.

Full freedom of action is provided when developing policies. You can create any state, transition to any other state, and specify any number of actions in each state.

ParameterDescriptionTypeRequiredRead Only
policy_idPolicy namestringYesYes
descriptionPolicy description in human-readable formatstringYesNo
ism_templateSpecified ISM template pattern matching the index for policy applicationnested list of objectsNoNo
last_updated_timeTime of the last policy updatetimestampYesYes
error_notificationDestination and message template for error notificationsobjectNoNo
default_stateDefault initial state for each index using this policystringYesNo
statesStates defined in the policynested list of objectsYesNo

States

A state is a description of the current status of a managed index. A managed index can be in only one state at a time. Each state has associated actions that are executed sequentially upon entering the state, and transitions that are evaluated after all actions are completed.

The following table describes the parameters that can be configured for a state:

FieldDescriptionTypeRequired
nameState namestringYes
actionsActions to be executed upon entering the state. Additional information is described in the "Actions" section.nested list of objectsYes
transitionsThe next states and the conditions required to transition into them. If there are no transitions, the policy is considered complete and may stop managing the index. Additional information is described in the "Transitions" section.nested list of objectsYes

Actions

Actions are the steps that a policy sequentially performs on an index when it enters a specific state.

ISM (Index State Management) executes actions in the order they are defined. For example, if actions [A, B, C, D] are specified, ISM performs action A and then goes into a sleep period, as configured by the cluster setting plugins.index_state_management.job_interval. After the sleep interval, ISM continues executing the remaining actions one by one. However, if ISM fails to successfully perform action A, the operation stops and actions B, C, and D are not executed. In such cases, a retry mechanism is available (described below).

Optionally, a timeout period can be defined for an action. If the timeout is exceeded, the operation is forcibly terminated. For example, if the timeout is set to 1d and the action is not completed within one day (even after retries), the action fails.

Each action can be configured with timeout and retry settings:

ParameterDescriptionTypeRequiredDefault
timeoutTimeout period for the action. Time units are accepted: minutes, hours, and days.time unitNo-
retryRetry configuration for this actionobjectNoAction-dependent

The retry operation has the following parameters:

ParameterDescriptionTypeRequiredDefault
countNumber of retry attemptsnumberYes-
backoffType of backoff policy used for retries. Valid values: Exponential, Constant, LinearstringNoExponential
delayWait time between retry attempts. Time units are accepted: minutes, hours, and daystime unitNo1 minute

The following example configures an action with a timeout of one hour. The policy retries the action up to three times using exponential backoff, with an initial delay of 10 minutes:

{
"actions": {
"timeout": "1h",
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "10m"
}
}
}

Operations supported by ISM

ISM supports the following actions:

Force Merge

Reduces the number of index segments by merging shard segments. Before starting the merge, ISM attempts to set the index to read-only.

ParameterDescriptionTypeRequired
max_num_segmentsThe number of segments to reduce the shard tonumberYes
wait_for_completionWhether to wait for the action to complete or return immediately after startbooleanNo
task_execution_timeoutTimeout for task execution. Only applies if wait_for_completion is falsestring (time unit)No
{
"force_merge": {
"max_num_segments": 1
}
}

Read Only

Sets the managed index to read-only mode.

{
"read_only": {}
}

Set the index.blocks.write parameter to true for the managed index.

warning

This block does not prevent the index from being updated.

Read Write

Sets the index to read-write mode.

Example configuration:

{
"read_write": {}
}

Replica Count

Sets the number of replicas for the index.

ParameterDescriptionTypeRequired
number_of_replicasDefines the number of replicas to assign to the index.numberYes
{
"replica_count": {
"number_of_replicas": 2
}
}

Shrink

Allows reducing the number of primary shards in an index. This action supports the following parameters:

ParameterDescriptionTypeRequired
num_new_shardsThe maximum number of primary shards in the shrunken index.integerYes, but cannot be used with max_shard_size or percentage_of_source_shards
max_shard_sizeThe maximum shard size in bytes for the target index.string (size unit, example values: 500mb, 1gb)Yes, but cannot be used with num_new_shards or percentage_of_source_shards
percentage_of_source_shardsThe percentage of the source primary shards to shrink. This parameter specifies the minimum percentage to use when shrinking the number of primary shards. Must be in the range from 0.0 to 1.0 (exclusive).numberYes, but cannot be used with max_shard_size or num_new_shards
target_index_name_templateThe name of the shrunken index. Accepts strings and Mustache variables (e.g., {"source": "_shrunken"}).stringNo
aliasesAliases to add to the new index.array<object>No
force_unsafeWhether to perform the action even when no replicas are present.booleanNo
{
"shrink": {
"num_new_shards": 1,
"target_index_name_template": {
"source": "_shrunken"
},
"aliases": [
{
"my-alias": {}
}
],
"force_unsafe": false
}
}

If aliases need to be assigned, the aliases parameter should contain an array of alias objects. For example:

"aliases": [
{
"my-alias": {}
},
{
"my-second-alias": {
"is_write_index": false,
"filter": {
"multi_match": {
"query": "QUEEN",
"fields": ["speaker", "text_entry"]
}
},
"index_routing" : "1",
"search_routing" : "1"
}
},
]