Créer une politique ISM Exemples de politiques Modèles ISM Différences

Gestion de l'état de l'index dans Amazon OpenSearch Service

La gestion de l'état des index (ISM) d'Amazon OpenSearch Service vous permet de définir des politiques de gestion personnalisées qui automatisent les tâches de routine et les appliquent aux index et aux modèles d'index. Vous n'avez plus besoin de configurer et de gérer des processus externes pour exécuter vos opérations d'index.

Chaque politique contient un état par défaut et une liste d'états pour la transition de l'index. Dans chaque état, vous pouvez définir une liste d'actions à effectuer et les conditions qui déclenchent ces transitions. Un cas d'utilisation typique consiste à supprimer périodiquement les anciens index après un certain temps. Par exemple, vous pouvez définir une politique qui déplace votre index dans un état read_only après 30 jours, puis les supprime après 90 jours.

Après avoir attaché une politique à un index, ISM crée une tâche qui s'exécute toutes les 5 à 8 minutes (ou 30 à 48 minutes pour les clusters antérieurs à 1.3) pour effectuer des actions de la politique, vérifier les conditions et faire passer l'index par différents états. En général, cette tâche est exécutée toutes les 5 minutes, plus une instabilité aléatoire de 0 à 60 % y est ajoutée pour vous assurer de ne pas voir un pic d'activité de tous vos indices en même temps. ISM n'exécute pas de tâches si l'état du cluster est rouge.

ISM nécessite OpenSearch Elasticsearch 6.8 ou version ultérieure.

Note

Cette documentation fournit un bref aperçu de l'ISM ainsi que plusieurs exemples de politiques. Il explique également en quoi l'ISM pour les domaines Amazon OpenSearch Service diffère de l'ISM sur les OpenSearch clusters autogérés. Pour une documentation complète d'ISM, y compris une référence complète des paramètres, une description de chaque paramètre et une référence d'API, consultez la section Gestion de l'état des index dans la OpenSearch documentation.

Important

Vous ne pouvez plus utiliser de modèles d'index pour appliquer des stratégies ISM aux index nouvellement créés. Vous pouvez continuer à gérer automatiquement les index nouvellement créés via le champ Modèle ISM. Cette mise à jour introduit un changement radical qui affecte les CloudFormation modèles existants utilisant ce paramètre.

Créer une politique ISM

Pour commencer à utiliser Index State Management

Ouvrez la console Amazon OpenSearch Service à l'adresse https://console.aws.amazon.com/aos/home.
Choisissez le domaine pour lequel vous voulez créer une stratégie ISM.
Depuis le tableau de bord du domaine, accédez à l'URL des OpenSearch tableaux de bord et connectez-vous à l'aide de votre nom d'utilisateur et de votre mot de passe principaux. Le format de l'URL est le suivant :
```
domain-endpoint/_dashboards/
```
Ouvrez le panneau de navigation de gauche dans les OpenSearch tableaux de bord et choisissez Gestion des index, puis Créer une politique.
Vous pouvez utiliser l'éditeur visuel ou l'éditeur JSON pour créer des stratégies. Nous vous recommandons d'utiliser l'éditeur visuel, car il offre un moyen plus structuré de définir les politiques. Afin d'obtenir de l'aide pour la création de stratégies, consultez les exemples de stratégies suivants.
Après avoir créé une stratégie, attachez-la à un ou plusieurs index :
```
POST _plugins/_ism/add/my-index
{
  "policy_id": "my-policy-id"
}
```
Note
Si votre domaine exécute une ancienne version d'Elasticsearch, utilisez _opendistro au lieu de _plugins.

Vous pouvez également sélectionner l'index dans les OpenSearch tableaux de bord et choisir Appliquer la politique.

Exemples de politiques

Les exemples de politique suivants montrent comment automatiser les cas d'utilisation ISM courants.

Stockage à chaud > stockage UltraWarm > stockage à froid

Cet exemple de politique déplace un index du stockage à chaud vers UltraWarm, et éventuellement vers stockage à froid. Ensuite, il supprime l'index.

L'état initial de l'index est hot. Après dix jours, ISM le fait passer à l'état warm. 80 jours plus tard, l'index a plus de 90 jours et passe à l'état cold. Après un an, le service envoie une notification à une salle Amazon Chime pour indiquer que l'index est en cours de suppression, puis le supprime définitivement.

Notez que les index froids requièrent l'opération cold_delete plutôt que l'opération delete normale. Notez également qu'un timestamp_field explicite est nécessaire dans vos données afin de gérer les index froids avec ISM.


{
  "policy": {
    "description": "Demonstrate a hot-warm-cold-delete workflow.",
    "default_state": "hot",
    "schema_version": 1,
    "states": [{
        "name": "hot",
        "actions": [],
        "transitions": [{
          "state_name": "warm",
          "conditions": {
            "min_index_age": "10d"
          }
        }]
      },
      {
        "name": "warm",
        "actions": [{
          "warm_migration": {},
          "retry": {
            "count": 5,
            "delay": "1h"
          }
        }],
        "transitions": [{
          "state_name": "cold",
          "conditions": {
            "min_index_age": "90d"
          }
        }]
      },
      {
        "name": "cold",
        "actions": [{
            "cold_migration": {
              "timestamp_field": "<your timestamp field>"
            }
          }
        ],
        "transitions": [{
          "state_name": "delete",
          "conditions": {
             "min_index_age": "365d"
          }
        }]
      },
      {
        "name": "delete",
        "actions": [{
          "notification": {
            "destination": {
              "chime": {
                "url": "<URL>"
              }
            },
            "message_template": {
              "source": "The index {{ctx.index}} is being deleted."
            }
          }
        },
        {
          "cold_delete": {}
        }]
      }
    ]
  }
}

Réduire le nombre de réplicas

Cet exemple de politique réduit le nombre de réplicas à zéro au bout de sept jours pour économiser de l'espace disque, puis supprime l'index au bout de 21 jours. Cette politique suppose que votre index n'est pas critique et ne reçoit plus de demandes d'écriture, et qu'aucun réplica ne comporte un risque de perte de données.


{
  "policy": {
    "description": "Changes replica count and deletes.",
    "schema_version": 1,
    "default_state": "current",
    "states": [{
        "name": "current",
        "actions": [],
        "transitions": [{
          "state_name": "old",
          "conditions": {
            "min_index_age": "7d"
          }
        }]
      },
      {
        "name": "old",
        "actions": [{
          "replica_count": {
            "number_of_replicas": 0
          }
        }],
        "transitions": [{
          "state_name": "delete",
          "conditions": {
            "min_index_age": "21d"
          }
        }]
      },
      {
        "name": "delete",
        "actions": [{
          "delete": {}
        }],
        "transitions": []
      }
    ]
  }
}

Prendre un instantané d'index

Cet exemple de politique utilise l'opération snapshot pour prendre un instantané d'un index dès qu'il contient au moins un document. repository correspond au nom du référentiel d'instantanés manuels que vous avez enregistré dans Amazon S3. snapshot correspond au nom de l'instantané. Pour connaître les prérequis relatifs aux instantanés ainsi que la procédure à suivre pour enregistrer un référentiel, consultez Création d'instantanés d'index dans Amazon Service OpenSearch .


{
  "policy": {
    "description": "Takes an index snapshot.",
    "schema_version": 1,
    "default_state": "empty",
    "states": [{
        "name": "empty",
        "actions": [],
        "transitions": [{
          "state_name": "occupied",
          "conditions": {
            "min_doc_count": 1
          }
        }]
      },
      {
        "name": "occupied",
        "actions": [{
          "snapshot": {
            "repository": "<my-repository>",
            "snapshot": "<my-snapshot>"
            }
          }],
          "transitions": []
      }
    ]
  }
}

Modèles ISM

Vous pouvez configurer un champ ism_template dans une politique afin que, lorsque vous créez un index qui correspond au modèle, la politique soit automatiquement attachée à cet index. Dans cet exemple, tout index créé dont le nom commence par « log » est automatiquement mis en correspondance avec la politique ISM my-policy-id :


PUT _plugins/_ism/policies/my-policy-id
{
  "policy": {
    "description": "Example policy.",
    "default_state": "...",
    "states": [...],
    "ism_template": {
      "index_patterns": ["log*"],
      "priority": 100
    }
  }
}

Pour un exemple plus détaillé, consultez Exemple de politique avec modèle ISM pour la substitution automatique.

Différences

Par rapport à OpenSearch Elasticsearch, ISM for Amazon OpenSearch Service présente plusieurs différences.

Opérations ISM

OpenSearch Le service prend en charge trois opérations ISM uniques warm_migrationcold_migration,, et cold_delete :
- Si votre domaine est UltraWarmactivé, l'warm_migrationaction fait passer l'index au stockage à chaud.
- Si le stockage à froid est activé sur votre domaine, l'action cold_migration fait passer l'index au stockage à froid et l'action cold_delete supprime l'index du stockage à froid.
Même si l'une de ces actions ne se termine pas dans le délai d'attente défini, la migration ou la suppression des index se poursuit. Définir une notification d'erreur error_notification pour l'une des actions ci-dessus vous permettra de savoir que l'action a échoué si elle ne s'est pas terminée dans le délai imparti, elle est toutefois uniquement destinée à votre propre référence. L'opération proprement dite n'a pas dépassé le délai d'attente et continue de s'exécuter jusqu'à ce qu'elle réussisse ou échoue.
Si votre domaine fonctionne avec Elasticsearch 7.4 OpenSearch ou version ultérieure, le OpenSearch Service prend en charge l'ISM open et close les opérations.

Si votre domaine fonctionne avec Elasticsearch 7.7 OpenSearch ou version ultérieure, le OpenSearch service prend en charge le fonctionnement ISMsnapshot.

Opérations ISM de stockage à froid

Pour les index cold, vous devez indiquer un paramètre ?type=_cold lorsque vous utilisez les API ISM suivantes :

Ces API pour les index à froid présentent les différences supplémentaires suivantes :

Les opérateurs de caractères génériques ne sont pas pris en charge, à moins que vous les utilisiez à la fin. Par exemple, _plugins/_ism/<add, remove, change_policy, retry, explain>/logstash-* est pris en charge, mais _plugins/_ism/<add, remove, change_policy, retry, explain>/iad-*-prod ne l'est pas.
Les modèles et noms à plusieurs index ne sont pas pris en charge. Par exemple, _plugins/_ism/<add, remove, change_policy, retry, explain>/app-logs est pris en charge, mais _plugins/_ism/<add, remove, change_policy, retry, explain>/app-logs,sample-data ne l'est pas.

Paramètres ISM

OpenSearch et Elasticsearch vous permettent de modifier tous les paramètres ISM disponibles à l'aide de l'_cluster/settingsAPI. Sur Amazon OpenSearch Service, vous ne pouvez modifier que les paramètres ISM suivants :

Paramètres au niveau du cluster :
- plugins.index_state_management.enabled
- plugins.index_state_management.history.enabled
Paramètres au niveau de l'index :
- plugins.index_state_management.rollover_alias

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Stockage OR1

Didacticiel : Automatisation des processus ISM