Merge pull request #394 from opensearch-project/regex-fix
Adjusted index pattern language
This commit is contained in:
commit
c7bebdcff6
|
@ -64,7 +64,7 @@ Some users report compatibility issues with ingest pipelines on these versions o
|
|||
| Elasticsearch OSS 7.10.2 | *Yes* | *Yes* | *No* | *Yes* |
|
||||
| ODFE 1.x to 1.12 | *Yes* | *Yes* | *No* | *Yes* |
|
||||
| ODFE 1.13 | *Yes* | *Yes* | *No* | *Yes* |
|
||||
| OpenSearch 1.0 | Yes via version setting | Yes via version setting | *No* | *Yes* |
|
||||
| OpenSearch 1.x | Yes via version setting | Yes via version setting | *No* | *Yes* |
|
||||
|
||||
\* Most current compatible version with Elasticsearch OSS.
|
||||
|
||||
|
@ -77,7 +77,7 @@ Some users report compatibility issues with ingest pipelines on these versions o
|
|||
| Elasticsearch OSS 7.10.2 | *Yes* | *Yes* | No |
|
||||
| ODFE 1.x to 1.12 | *Yes* | *Yes* | No |
|
||||
| ODFE 1.13 | *Yes* | *Yes* | No |
|
||||
| OpenSearch 1.0 | Yes via version setting | Yes via version setting | No |
|
||||
| OpenSearch 1.x | Yes via version setting | Yes via version setting | No |
|
||||
| Logstash OSS 7.x to 7.11.x | *Yes* | *Yes* | *Yes* |
|
||||
| Logstash OSS 7.12.x\* | *Yes* | *Yes* | *Yes* |
|
||||
| Logstash 7.13.x with OpenSearch output plugin | *Yes* | *Yes* | *Yes* |
|
||||
|
|
|
@ -7,7 +7,7 @@ nav_order: 20
|
|||
|
||||
# ISM API
|
||||
|
||||
Use the index state management operations to programmatically work with policies and managed indices.
|
||||
Use the index state management operations to programmatically work with policies and managed indexes.
|
||||
|
||||
---
|
||||
|
||||
|
@ -163,8 +163,8 @@ POST _plugins/_ism/add/index_1
|
|||
}
|
||||
```
|
||||
|
||||
If you use a wildcard `*` while adding a policy to an index, the ISM plugin interprets `*` as all indices, including system indices like `.opendistro-security`, which stores users, roles, and tenants. A delete action in your policy might accidentally delete all user roles and tenants in your cluster.
|
||||
Don't use the broad `*` wildcard, and instead add a prefix, such as `my-logs*`, when specifying indices with the `_ism/add` API.
|
||||
If you use a wildcard `*` while adding a policy to an index, the ISM plugin interprets `*` as all indexes, including system indexes like `.opendistro-security`, which stores users, roles, and tenants. A delete action in your policy might accidentally delete all user roles and tenants in your cluster.
|
||||
Don't use the broad `*` wildcard, and instead add a prefix, such as `my-logs*`, when specifying indexes with the `_ism/add` API.
|
||||
{: .warning }
|
||||
|
||||
---
|
||||
|
@ -390,9 +390,9 @@ POST _plugins/_ism/remove/index_1
|
|||
Introduced 1.0
|
||||
{: .label .label-purple }
|
||||
|
||||
Updates the managed index policy to a new policy (or to a new version of the policy). You can use an index pattern to update multiple indices at once. When updating multiple indices, you might want to include a state filter to only affect certain managed indices. The change policy filters out all the existing managed indices and only applies the change to the ones in the state that you specify. You can also explicitly specify the state that the managed index transitions to after the change policy takes effect.
|
||||
Updates the managed index policy to a new policy (or to a new version of the policy). You can use an index pattern to update multiple indexes at once. When updating multiple indexes, you might want to include a state filter to only affect certain managed indexes. The change policy filters out all the existing managed indexes and only applies the change to the ones in the state that you specify. You can also explicitly specify the state that the managed index transitions to after the change policy takes effect.
|
||||
|
||||
A policy change is an asynchronous background process. The changes are queued and are not executed immediately by the background process. This delay in execution protects the currently running managed indices from being put into a broken state. If the policy you are changing to has only some small configuration changes, then the change takes place immediately. For example, if the policy changes the `min_index_age` parameter in a rollover condition from `1000d` to `100d`, this change takes place immediately in its next execution. If the change modifies the state, actions, or the order of actions of the current state the index is in, then the change happens at the end of its current state before transitioning to a new state.
|
||||
A policy change is an asynchronous background process. The changes are queued and are not executed immediately by the background process. This delay in execution protects the currently running managed indexes from being put into a broken state. If the policy you are changing to has only some small configuration changes, then the change takes place immediately. For example, if the policy changes the `min_index_age` parameter in a rollover condition from `1000d` to `100d`, this change takes place immediately in its next execution. If the change modifies the state, actions, or the order of actions of the current state the index is in, then the change happens at the end of its current state before transitioning to a new state.
|
||||
|
||||
In this example, the policy applied on the `index_1` index is changed to `policy_1`, which could either be a completely new policy or an updated version of its existing policy. The process only applies the change if the index is currently in the `searches` state. After this change in policy takes place, `index_1` transitions to the `delete` state.
|
||||
|
||||
|
@ -428,7 +428,7 @@ POST _plugins/_ism/change_policy/index_1
|
|||
Introduced 1.0
|
||||
{: .label .label-purple }
|
||||
|
||||
Retries the failed action for an index. For the retry call to succeed, ISM must manage the index, and the index must be in a failed state. You can use index patterns (`*`) to retry multiple failed indices.
|
||||
Retries the failed action for an index. For the retry call to succeed, ISM must manage the index, and the index must be in a failed state. You can use index patterns (`*`) to retry multiple failed indexes.
|
||||
|
||||
#### Request
|
||||
|
||||
|
@ -456,7 +456,7 @@ POST _plugins/_ism/retry/index_1
|
|||
Introduced 1.0
|
||||
{: .label .label-purple }
|
||||
|
||||
Gets the current state of the index. You can use index patterns to get the status of multiple indices.
|
||||
Gets the current state of the index. You can use index patterns to get the status of multiple indexes.
|
||||
|
||||
#### Request
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ has_toc: false
|
|||
OpenSearch Dashboards
|
||||
{: .label .label-yellow :}
|
||||
|
||||
If you analyze time-series data, you likely prioritize new data over old data. You might periodically perform certain operations on older indices, such as reducing replica count or deleting them.
|
||||
If you analyze time-series data, you likely prioritize new data over old data. You might periodically perform certain operations on older indexes, such as reducing replica count or deleting them.
|
||||
|
||||
Index State Management (ISM) is a plugin that lets you automate these periodic, administrative operations by triggering them based on changes in the index age, index size, or number of documents. Using the ISM plugin, you can define *policies* that automatically handle index rollovers or deletions to fit your use case.
|
||||
|
||||
|
@ -39,8 +39,8 @@ You can use the visual editor or JSON editor to create policies. Compared to the
|
|||
2. Choose **Create policy**.
|
||||
3. Choose **Visual editor**.
|
||||
4. In the **Policy info** section, enter a policy ID and an optional description.
|
||||
5. In the **Error notification** section, set up an optional error notification that gets sent whenever a policy execution fails. For more information, see [Error notifications]({{site.url}}{{site.baseurl}}/im-plugin/ism/policies#error-notifications). If you're using auto rollovers in your policy, we recommend setting up error notifications, which notify you of unexpectedly large indices if rollovers fail.
|
||||
6. In **ISM templates**, enter any ISM template patterns to automatically apply this policy to existing and future indices. For example, if you specify a template of `sample-index*`, the ISM plugin automatically applies this policy to any indices whose names start with `sample-index`.
|
||||
5. In the **Error notification** section, set up an optional error notification that gets sent whenever a policy execution fails. For more information, see [Error notifications]({{site.url}}{{site.baseurl}}/im-plugin/ism/policies#error-notifications). If you're using auto rollovers in your policy, we recommend setting up error notifications, which notify you of unexpectedly large indexes if rollovers fail.
|
||||
6. In **ISM templates**, enter any ISM template patterns to automatically apply this policy to existing and future indexes. For example, if you specify a template of `sample-index*`, the ISM plugin automatically applies this policy to any indexes whose names start with `sample-index`. Your pattern cannot contain any of the following characters: `:`, `"`, `+`, `/`, `\`, `|`, `?`, `#`, `>`, and `<`.
|
||||
7. In **States**, add any states you want to include in the policy. Each state has [actions]({{site.url}}{{site.baseurl}}/im-plugin/ism/policies/#actions) the plugin executes when the index enters a certain state, and [transitions]({{site.url}}{{site.baseurl}}/im-plugin/ism/policies/#transitions), which have conditions that, when met, transition the index into a destination state. The first state you create in a policy is automatically set as the initial state. Each policy must have at least one state, but actions and transitions are optional.
|
||||
8. Choose **Create**.
|
||||
|
||||
|
@ -54,10 +54,10 @@ You can use the visual editor or JSON editor to create policies. Compared to the
|
|||
5. In the **Define policy** section, enter your policy.
|
||||
6. Choose **Create**.
|
||||
|
||||
After you create a policy, your next step is to attach it to an index or indices.
|
||||
After you create a policy, your next step is to attach it to an index or indexes.
|
||||
You can set up an `ism_template` in the policy so when an index that matches the ISM template pattern is created, the plugin automatically attaches the policy to the index.
|
||||
|
||||
The following example demonstrates how to create a policy that automatically gets attached to all indices whose names start with `index_name-`.
|
||||
The following example demonstrates how to create a policy that automatically gets attached to all indexes whose names start with `index_name-`.
|
||||
|
||||
```json
|
||||
PUT _plugins/_ism/policies/policy_id
|
||||
|
@ -94,13 +94,13 @@ PUT _index_template/<template_name>
|
|||
}
|
||||
```
|
||||
|
||||
The `opendistro.index_state_management.policy_id` setting is deprecated. You can continue to automatically manage newly created indices with the ISM template field.
|
||||
The `opendistro.index_state_management.policy_id` setting is deprecated. You can continue to automatically manage newly created indexes with the ISM template field.
|
||||
{: .note }
|
||||
|
||||
### Step 2: Attach policies to indices
|
||||
### Step 2: Attach policies to indexes
|
||||
|
||||
1. Choose **Indices**.
|
||||
2. Choose the index or indices that you want to attach your policy to.
|
||||
1. Choose **indexes**.
|
||||
2. Choose the index or indexes that you want to attach your policy to.
|
||||
3. Choose **Apply policy**.
|
||||
4. From the **Policy ID** menu, choose the policy that you created.
|
||||
You can see a preview of your policy.
|
||||
|
@ -112,13 +112,13 @@ After you attach a policy to an index, ISM creates a job that runs every 5 minut
|
|||
|
||||
ISM does not run jobs if the cluster state is red.
|
||||
|
||||
### Step 3: Manage indices
|
||||
### Step 3: Manage indexes
|
||||
|
||||
1. Choose **Managed Indices**.
|
||||
2. To change your policy, see [Change Policy]({{site.url}}{{site.baseurl}}/im-plugin/ism/managedindices#change-policy).
|
||||
1. Choose **Managed indexes**.
|
||||
2. To change your policy, see [Change Policy]({{site.url}}{{site.baseurl}}/im-plugin/ism/managedindexes#change-policy).
|
||||
3. To attach a rollover alias to your index, select your policy and choose **Add rollover alias**.
|
||||
Make sure that the alias that you enter already exists. For more information about the rollover operation, see [rollover]({{site.url}}{{site.baseurl}}/im-plugin/ism/policies#rollover).
|
||||
4. To remove a policy, choose your policy, and then choose **Remove policy**.
|
||||
5. To retry a policy, choose your policy, and then choose **Retry policy**.
|
||||
|
||||
For information about managing your policies, see [Managed Indices]({{site.url}}{{site.baseurl}}/im-plugin/ism/managedindices/).
|
||||
For information about managing your policies, see [Managed indexes]({{site.url}}{{site.baseurl}}/im-plugin/ism/managedindexes/).
|
||||
|
|
|
@ -16,7 +16,7 @@ To create an index template, use a POST request:
|
|||
POST _index_template
|
||||
```
|
||||
|
||||
This command creates a template named `daily_logs` and applies it to any new index whose name matches the regular expression `logs-2020-01-*` and also adds it to the `my_logs` alias:
|
||||
This command creates a template named `daily_logs` and applies it to any new index whose name matches the pattern `logs-2020-01-*` and also adds it to the `my_logs` alias:
|
||||
|
||||
```json
|
||||
PUT _index_template/daily_logs
|
||||
|
@ -97,6 +97,8 @@ GET logs-2020-01-01
|
|||
|
||||
Any additional indices that match this pattern---`logs-2020-01-02`, `logs-2020-01-03`, and so on---will inherit the same mappings and settings.
|
||||
|
||||
Index patterns cannot contain any of the following characters: `:`, `"`, `+`, `/`, `\`, `|`, `?`, `#`, `>`, and `<`.
|
||||
|
||||
### Retrieve a template
|
||||
|
||||
To list all index templates:
|
||||
|
|
Loading…
Reference in New Issue