Automatisation de la gestion de l'état de l'index pour Amazon OpenSearch Service (successeur d'Amazon Elasticsearch Service)

Republié par Platon

Suiveurs: 0

En ce qui concerne les données de séries chronologiques, il est plus courant d'accéder à de nouvelles données qu'à des données existantes, telles que les quatre dernières heures ou une journée. Souvent, les équipes d'application doivent gérer plusieurs index pour diverses charges de travail de données, ce qui entraîne de nouvelles exigences pour mettre en place une solution personnalisée pour gérer les cycles de vie des index. Cela devient fastidieux à mesure que les index augmentent, et cela entraîne des frais généraux de maintenance.

Service Amazon OpenSearch (successeur d'Amazon Elasticsearch Service) vous permet d'automatiser les activités récurrentes de gestion des index. Cela évite d'avoir à utiliser des outils supplémentaires pour gérer les cycles de vie des index. Gestion de l'état de l'index (ISM) vous permet de créer une politique qui automatise ces opérations en fonction de l'âge, de la taille et d'autres conditions de l'index, le tout depuis votre domaine Amazon OpenSearch Service.

Dans cet article, nous expliquons comment implémenter une stratégie pour automatiser les tâches de routine de gestion des index et les appliquer aux index et aux modèles d'index.

Pré-requis

Avant de commencer, assurez-vous de remplir les conditions préalables suivantes :

Avoir Elasticsearch 6.8 ou version ultérieure (requis pour utiliser ISM et UltraWarm) ou Configurer un nouveau domaine Amazon OpenSearch Service avec UltraWarm activé.
Enregistrer un référentiel d'instantanés manuel pour votre nouveau domaine.
Assurez-vous que votre rôle d'utilisateur dispose des autorisations suffisantes pour accéder à la console Kibana du domaine Amazon OpenSearch Service. Si nécessaire, validez et configurer l'accès à vos domaines.

Cas d'utilisation

Amazon OpenSearch Service prend en charge trois niveaux de stockage : le "chaud" par défaut pour l'écriture active et l'analyse à faible latence, UltraChaud pour les données en lecture seule jusqu'à trois pétaoctets à un dixième du coût du niveau chaud, et du froid pour un archivage à long terme illimité. Bien que le stockage à chaud soit utilisé pour indexer et fournir l'accès le plus rapide, UltraWarm complète le niveau de stockage à chaud en fournissant un stockage moins coûteux pour les données plus anciennes et moins fréquemment consultées. Cela se fait tout en conservant la même expérience d'analyse interactive. Plutôt que le stockage attaché, les nœuds UltraWarm utilisent Service de stockage simple Amazon (Amazon S3) et une solution de mise en cache sophistiquée pour améliorer les performances.

Pour démontrer la fonctionnalité, nous présentons un exemple de cas d'utilisation de la gestion de données de séries chronologiques dans des indices quotidiens. Dans ce cas d'utilisation, nous prenons automatiquement un instantané de chaque index après 24 heures, puis nous migrons l'index de l'état chaud par défaut vers le stockage UltraWarm après deux jours, le stockage froid après 30 jours, et enfin supprimons l'index après 60 jours.

Après avoir créé le domaine Amazon OpenSearch Service et enregistré un référentiel d'instantanés, procédez comme suit :

Attendez que l'état du domaine devienne actif et choisissez le point de terminaison Kibana.
Connectez-vous à l'aide du point de terminaison de l'interface utilisateur Kibana.
Sur la page d'accueil de Kibana, ajoutez tous les exemples de données répertoriés en choisissant Essayer nos exemples de données et en choisissant Ajouter des données.
Après avoir ajouté les données, choisissez Index Management (l'icône IM dans le volet de navigation de gauche), qui atterrit sur la page Index Policies.
Choisissez Créer une stratégie.
Pour Stratégie de nom, saisissez ism-policy-example.
Remplacez la stratégie par défaut par la stratégie suivante :

{ "policy": { "description": "Demonstrate a hot-snapshot-warm-cold-delete workflow.", "default_state": "hot", "states": [ { "name": "hot", "actions": [], "transitions": [ { "state_name": "snapshot", "conditions": { "min_index_age": "24h" } } ] }, { "name": "snapshot", "actions": [ { "retry": { "count": 5, "backoff": "exponential", "delay": "30m" }, "snapshot": { "repository": "snapshot-repo", "snapshot": "ism-snapshot" } } ], "transitions": [ { "state_name": "warm", "conditions": { "min_index_age": "2d" } } ] }, { "name": "warm", "actions": [ { "retry": { "count": 5, "backoff": "exponential", "delay": "1h" }, "warm_migration": {} } ], "transitions": [ { "state_name": "cold", "conditions": { "min_index_age": "30d" } } ] }, { "name": "cold", "actions": [ { "retry": { "count": 5, "backoff": "exponential", "delay": "1h" }, "cold_migration": { "start_time": null, "end_time": null, "timestamp_field": "@timestamp", "ignore": "none" } } ], "transitions": [ { "state_name": "delete", "conditions": { "min_index_age": "60d" } } ] }, { "name": "delete", "actions": [ { "cold_delete": {} } ], "transitions": [] } ], "ism_template": [ { "index_patterns": [ "index-*" ], "priority": 100 } ] }
}

Notez que la dernière section de la politique, "ism_template", est utilisée pour attacher automatiquement la politique ISM à tout index nouvellement créé qui correspond aux index_patterns. Vous pouvez définir plusieurs modèles.

De plus, vous pouvez utiliser le API ISM pour travailler par programmation avec des stratégies et des index gérés.

Choisissez Créer. Vous pouvez maintenant voir votre politique d'indexation sur la page Politiques d'indexation.
Sur la page Indices, recherchez kibana_sample, qui doit répertorier tous les exemples d'index de données que vous avez ajoutés précédemment.
Sélectionnez tous les index et choisissez Apply policy.
Dans le menu déroulant Policy ID, choisissez la stratégie créée à l'étape précédente.
Choisissez Appliquer.

La stratégie est maintenant affectée et commence à gérer les index. Sur la page Indices gérés, vous pouvez observer l'état comme Initializing.

Une fois l'initialisation terminée, l'état passe à Running.

Vous pouvez également définir une fréquence d'actualisation pour actualiser les informations d'état des index gérés.

Démystifier la politique

Dans cette section, nous expliquons la politique d'indexation et sa structure.

Les stratégies sont des documents JSON qui définissent les éléments suivants :

Les états dans lesquels un index peut se trouver
Toutes les actions que vous souhaitez que le plug-in entreprenne lorsqu'un index entre dans l'état
Conditions qui doivent être remplies pour qu'un index se déplace ou passe à un nouvel état

Le document de politique commence par des métadonnées de base telles que description, default_state que l'index doit entrer, et enfin une série de définitions d'état.

A Etat est l'état dans lequel se trouve actuellement l'index géré. Un index géré ne peut être que dans un seul état à la fois. Chaque état a des actions associées qui sont exécutées séquentiellement lors de l'entrée dans un état, et des transitions qui sont vérifiées une fois toutes les actions terminées.

Le premier état est chaudes. Dans ce cas d'utilisation, aucune action n'est définie dans cet état chaud. De plus, les index gérés atterrissent initialement dans cet état, puis passent à instantané, chaud, froid, et enfin effacer. Les transitions définissent les conditions qui doivent être remplies pour qu'un état change (dans ce cas, passer à instantané après que l'indice ait franchi 24 heures).

Nous pouvons rapidement vérifier le statut dans la section Index Management de Kibana. Chaque index aura des détails d'état répertoriés sous Indices gérés par la politique.

Vous pouvez également le vérifier sur la console Amazon OpenSearch Service dans les colonnes Utilisation du stockage Ultrawarm et Utilisation du stockage froid.

Le dernier état du document de stratégie marque les index à supprimer en fonction des actions. Cet état de stratégie suppose que votre index n'est pas critique et ne reçoit plus de demandes d'écriture. L'absence de réplicas comporte un certain risque de perte de données.

Entre autres actions, vous pouvez également configurer la notification pour envoyer des informations d'action de stratégie à Chime, Slack, ou une URL de webhook. Les détails complets peuvent être trouvés ici.

La capture d'écran suivante montre l'état de l'index sur la console.

Informations complémentaires sur les politiques ISM

Si vous avez un domaine Amazon OpenSearch Service existant sans prise en charge d'UltraWarm (en raison de condition préalables), vous pouvez utiliser des opérations de stratégie read_only et les reduces_replicas pour remplacer l'état chaud. Le code suivant est le modèle de stratégie pour ces deux états :

{ "name": "reduce_replicas", "actions": [{ "replica_count": { "number_of_replicas": 0 } }], "transitions": [{ "state_name": "read_only", "conditions": { "min_index_age": "2d" } }] }, { "name": "read_only", "actions": [ { "read_only": {} } ], "transitions": [ { "state_name": "delete", "conditions": { "min_index_age": "3d" } } ] },

Résumé

Dans cet article, vous avez appris à utiliser la fonctionnalité ISM avec les niveaux de stockage UltraWarm et froid pour Amazon OpenSearch Service. La procédure pas à pas a illustré comment gérer les index à l'aide de ce plug-in avec un exemple de politique de cycle de vie.

Pour plus d'informations sur le plugin ISM, voir Gestion de l'état de l'index. Si vous avez besoin d'améliorations ou si vous avez d'autres demandes de fonctionnalités, veuillez déposer un aide. Pour vous impliquer dans le projet, consultez Directives de contribution.

Une grande chose à retenir pour moi lorsque j'ai évalué le plugin ISM dans Amazon OpenSearch Service était que le plugin ISM est entièrement compatible et fonctionne sur n'importe quel déploiement de l'open source Logiciel OpenSearch. Pour plus d'informations, voir Gestion de l'état de l'index dans la documentation OpenSearch.