1. Utilisation de l'_mapping API pour récupérer des informations sur les champs

2. Utilisation de l'_search API pour afficher les valeurs des champs

3. Filtrage des champs à l'aide du fields paramètre

4. Affichage des champs imbriqués

1. Utilisation de l'API _mapping pour récupérer des informations sur les champs

L'API _mapping vous permet de récupérer la définition du mappage pour un ou plusieurs index. Il s'agit d'informations sur les champs, leurs types de données et d'autres propriétés. Pour récupérer le mappage d'un index spécifique, utilisez la requête suivante :

Par exemple, si vous avez un index nommé my_index, vous pouvez récupérer son mapping avec la requête suivante :

La réponse comprendra la définition du mappage pour l'index, qui contient des informations sur les champs et leurs propriétés.

Il est également possible de récupérer la cartographie d'un champ spécifique. Cela peut s'avérer utile si votre cartographie est assez vaste et que vous souhaitez vous concentrer sur un domaine spécifique. Pour récupérer la correspondance d'un champ spécifique, utilisez la requête suivante :

Vous pouvez également récupérer les correspondances de plusieurs champs en séparant leurs noms par des virgules, comme dans la requête suivante :

2. Utilisation de l'API _search pour afficher les valeurs des champs

Pour afficher les valeurs des champs d'un index Elasticsearch, vous pouvez utiliser l'API _search. Par défaut, l'API _search renvoie le champ _source, qui contient le document JSON original qui a été indexé. Pour n'afficher que des champs spécifiques, vous pouvez utiliser le paramètre _source dans la requête de recherche.

Voici un exemple de demande de recherche qui renvoie les valeurs des champs title et author pour les documents de l'index my_index:

Dans cet exemple, le paramètre _source spécifie les champs à renvoyer.

3. Filtrer les champs à l'aide du paramètre fields

Vous pouvez également utiliser le paramètre fields pour filtrer les champs renvoyés dans la réponse de recherche. Cela peut être utile si vous n'avez besoin que de champs spécifiques et que vous souhaitez réduire la taille de la réponse. Le paramètre fields accepte un tableau de noms de champs ou de caractères génériques.

Par exemple, pour obtenir uniquement les champs title et author pour les documents de l'index my_index, vous pouvez utiliser la requête de recherche suivante :

Notez que le paramètre _source est fixé à false afin de ne pas renvoyer le document source.

Pour obtenir tous les champs dont le type de données est text, vous pouvez utiliser un motif joker comme celui-ci :

4. Affichage des champs imbriqués

Si votre index contient des champs imbriqués, vous pouvez utiliser la notation point pour spécifier le chemin du champ imbriqué dans le paramètre fields. Par exemple, si vous disposez d'un champ imbriqué nommé address.city, vous pouvez l'inclure dans la réponse de recherche comme suit :

Dans cet exemple, la réponse de la recherche comprendra les valeurs des champs title, author et address.city.

Conclusion

En conclusion, l'affichage des champs dans un index Elasticsearch peut être réalisé en utilisant l'API _mapping pour récupérer les informations sur les champs et l'API _search pour afficher les valeurs des champs. Vous pouvez filtrer les champs renvoyés dans la réponse de recherche à l'aide des paramètres _source ou fields et afficher les champs imbriqués à l'aide de la notation par points. Ces techniques peuvent vous aider à comprendre la structure de vos données, à identifier des champs spécifiques et à résoudre des problèmes.

Historique des filigranes

Il existe différents seuils "en filigrane" sur votre cluster Elasticsearch qui vous aident à suivre l'espace disque disponible. Lorsque le disque d'un nœud se remplit, le premier seuil à être franchi est le "filigrane de disque faible". Le deuxième seuil sera alors le "seuil de filigrane de disque élevé". Enfin, le "stade de l'inondation du disque" sera atteint. Une fois ce seuil dépassé, le cluster bloque l'écriture dans TOUS les index qui ont un shard (primaire ou réplique) sur le nœud qui a passé le filigrane. Les lectures (recherches) restent possibles.

Comment prévenir et gérer les cas où le disque est trop plein (surutilisation) ?

Il existe plusieurs méthodes pour gérer les cas où le disque Elasticsearch est trop plein :

1. Supprimer les anciennes données : En général, les données ne doivent pas être conservées indéfiniment. L'un des moyens de prévenir et de résoudre le problème des disques trop pleins est de veiller à ce que les données atteignant un certain âge soient archivées et supprimées de manière fiable. L'un des moyens d'y parvenir est d'utiliser l'ILM.

2. Augmenter la capacité de stockage : Si vous ne pouvez pas supprimer les données, vous pouvez ajouter des nœuds de données supplémentaires ou augmenter la taille des disques afin de conserver toutes les données sans nuire aux performances. Si vous devez ajouter de la capacité de stockage à la grappe, vous devez déterminer si vous devez ajouter uniquement de la capacité de stockage, ou à la fois de la capacité de stockage et des ressources RAM et CPU en proportion (voir la section sur le rapport entre la taille du disque, la RAM et le CPU ci-dessous).

Comment ajouter de la capacité de stockage à votre cluster Elasticsearch ?

1. Augmentez le nombre de nœuds de données : N'oubliez pas que les nouveaux nœuds doivent être de la même taille que les nœuds existants et de la même version d'Elasticsearch.

2. Augmenter la taille des nœuds existants : Dans les environnements en nuage, il est généralement facile d'augmenter la taille du disque et la RAM/CPU sur les nœuds existants.

3. Augmentez uniquement la taille du disque : Dans les environnements en nuage, il est souvent relativement facile d'augmenter la taille du disque.

4. Instantané et restauration: Si vous souhaitez que les anciennes données soient récupérées sur demande dans le cadre d'un processus automatisé à partir des sauvegardes, vous pouvez prendre des clichés des anciens index, les supprimer et restaurer temporairement les données sur demande à partir des clichés. 

5. Réduire le nombre de répliques par groupe : Une autre option pour réduire les données consiste à réduire le nombre de répliques de chaque groupe. Pour des raisons de haute disponibilité, il est préférable d'avoir une réplique par bloc de données, mais lorsque les données vieillissent, il est possible de se passer de répliques. Cela peut généralement fonctionner si les données sont persistantes ou si vous disposez d'une sauvegarde à restaurer en cas de besoin.

6. Créer des alertes : Afin d'éviter que les disques ne se remplissent à l'avenir et d'agir de manière proactive, vous devriez créer des alertes basées sur l'utilisation du disque qui vous préviendront lorsque le disque commencera à se remplir. 

Comment prévenir et traiter les cas où la capacité du disque est sous-utilisée ?

Si la capacité de votre disque est sous-utilisée, il existe plusieurs options pour réduire le volume de stockage de votre cluster.

Comment réduire le volume de stockage d'un cluster Elasticsearch ?

Il existe plusieurs méthodes pour réduire le volume de stockage d'un cluster.

1. Réduire le nombre de nœuds de données

Si vous souhaitez réduire le stockage des données et réduire les ressources RAM et CPU dans la même proportion, il s'agit de la stratégie la plus simple. Le déclassement des nœuds inutiles devrait permettre de réaliser les économies les plus importantes.

Avant de mettre le nœud hors service, vous devez.. :

• Assurez-vous que le nœud à mettre hors service n'est pas nécessaire en tant que nœud MASTER. Vous devez toujours avoir au moins trois nœuds ayant le rôle de nœud MASTER.

• Migrer les blocs de données hors du nœud à mettre hors service.

2. Remplacer les nœuds existants par des nœuds plus petits

Si vous ne pouvez pas réduire davantage le nombre de nœuds (en général, 3 est une configuration minimale), vous pouvez alors réduire la taille des nœuds existants. Il est conseillé de veiller à ce que tous les nœuds de données aient la même mémoire RAM et la même taille de disque, étant donné que l'équilibre des ensembles est basé sur le nombre d'ensembles par nœud.

La procédure serait la suivante :

• Ajouter de nouveaux nœuds plus petits à la grappe

• Faire migrer les shards à l'écart des nœuds à déclasser

• Arrêter les anciens nœuds

3. Réduire la taille des disques sur les nœuds

Si vous souhaitez uniquement réduire la taille des disques sur les nœuds sans modifier la mémoire vive ou l'unité centrale de la grappe, vous pouvez réduire la taille des disques pour chaque nœud. La réduction de la taille du disque sur un nœud Elasticsearch n'est pas un processus trivial.

La manière la plus simple de le faire est généralement d'effectuer les opérations suivantes :

• Migrations de shards depuis le nœud

• Arrêter le nœud

• Monter un nouveau volume de données sur le nœud avec la taille appropriée

• Copier toutes les données de l'ancien volume de disque vers le nouveau volume

• Détacher l'ancien volume A

• Démarrer le nœud et migrer les unités de stockage vers le nœud

Pour ce faire, vous devez disposer d'une capacité suffisante sur les autres nœuds pour stocker temporairement les fragments supplémentaires du nœud au cours de ce processus. Dans de nombreux cas, le coût de la gestion de ce processus peut dépasser les économies potentielles en termes d'utilisation du disque. Pour cette raison, il peut être plus simple de remplacer le nœud par un nouveau nœud ayant la taille de disque souhaitée (voir "Remplacer les nœuds existants par des nœuds plus petits" ci-dessus).

Lorsque vous payez pour des ressources inutiles, il est évident que vous pouvez réduire les coûts en optimisant l'utilisation de vos ressources.

La relation entre la taille du disque, la mémoire vive et le processeur

Le rapport idéal entre la capacité des disques et la mémoire vive dans votre cluster dépend de votre cas d'utilisation particulier. C'est pourquoi, lorsque vous envisagez de modifier votre capacité de stockage, vous devez également vous demander si vos ratios actuels Disque/RAM/CPU sont bien équilibrés et si, par conséquent, vous devez également ajouter/réduire la RAM/CPU dans les mêmes proportions.

Les besoins en RAM et en CPU dépendent du volume de l'activité d'indexation, du nombre et du type de requêtes, ainsi que de la quantité de données recherchées et agrégées. Elle est souvent proportionnelle à la quantité de données stockées sur la grappe, et doit donc également être liée à la taille du disque.

Le rapport entre la capacité du disque et la mémoire vive peut varier en fonction du cas d'utilisation. Voir quelques exemples ici :

Activité de l'indice

Conservation

Activité de recherche

Capacité du disque

RAM

Application de recherche d'entreprise

Ingestion modérée de billes

Longues

Lumière

2TB

32GB

Surveillance des applications

Ingestion intensive de bois

Court

Lumière

1TB

32GB

Commerce électronique

Indexation des données légères

Indéfinie

Lourd

500GB

32GB

N'oubliez pas que la modification de la configuration des machines des nœuds doit être effectuée avec précaution, car elle peut entraîner l'arrêt du nœud et vous devez veiller à ce que les fragments ne commencent pas à migrer vers vos autres nœuds déjà surchargés.

Le rôle des répliques dans Elasticsearch

Dans Elasticsearch, un index est une collection de documents qui sont répartis sur plusieurs shards primaires. Chaque groupe primaire est un index Apache Lucene autonome, et les documents d'un index sont répartis entre tous les groupes primaires. Pour garantir la haute disponibilité et la redondance des données, Elasticsearch permet à chaque nuage d'avoir une ou plusieurs copies, appelées répliques. Le paramètre number_of_replicas contrôle le nombre de répliques (copies) qu'Elasticsearch crée pour chaque réplique primaire d'un index. Par défaut, Elasticsearch crée une réplique pour chaque shard primaire, mais cela peut être modifié en fonction des besoins de votre système.

Configuration du nombre de répliques (number_of_replicas)

Le paramètre number_of_replicas peut être configuré au moment de la création de l'index ou mis à jour ultérieurement. Voici comment vous pouvez le définir lors de la création de l'index :

Dans cet exemple, Elasticsearch créera deux réplicas pour chaque fichier primaire de l'index my_index.

Pour mettre à jour le paramètre number_of_replicas d'un index existant, vous pouvez utiliser l'API _settings:

Cette commande mettra à jour l'index my_index pour qu'il y ait trois réplicas pour chaque groupe primaire.

Implications du paramètre number_of_replicas (nombre de répliques)

Le paramètre number_of_replicas a un impact significatif sur les performances et la résilience de votre cluster Elasticsearch. Voici quelques points clés à prendre en considération :

1. Redondance et disponibilité des données : L'augmentation du site number_of_replicas améliore la disponibilité de vos données en créant davantage de copies de chaque groupe de données. Si un nœud tombe en panne, Elasticsearch peut toujours servir des données à partir des répliques sur les nœuds restants.

2. Performances de recherche : Les répliques peuvent répondre à des demandes de lecture. Le fait de disposer d'un plus grand nombre de répliques peut donc améliorer les performances en matière de recherche en répartissant la charge sur un plus grand nombre de répliques.

3. Performance d'écriture : Cependant, chaque opération d'écriture doit être exécutée sur chaque copie d'un groupe de données. Par conséquent, une adresse number_of_replicas plus élevée peut ralentir les performances d'indexation car elle augmente le nombre d'opérations à effectuer pour chaque écriture.

4. Exigences en matière de stockage : Plus il y a de répliques, plus il y a d'espace de stockage. Vous devez vous assurer que votre cluster dispose d'une capacité suffisante pour stocker les répliques supplémentaires.

5. Résilience en cas de défaillance d'un nœud : Le site number_of_replicas doit être défini en fonction du nombre de nœuds de votre cluster. Si le site number_of_replicas est égal ou supérieur au nombre de nœuds, votre cluster peut tolérer la défaillance de plusieurs nœuds sans perte de données.

Bonnes pratiques pour définir le nombre de répliques (number_of_replicas)

Le réglage optimal de number_of_replicas dépend des exigences spécifiques de votre système. Toutefois, voici quelques bonnes pratiques générales :

• Pour un cluster à un seul nœud, number_of_replicas doit être fixé à 0, car il n'y a pas d'autres nœuds pour contenir des répliques.

• Pour un cluster à plusieurs nœuds, number_of_replicas doit être réglé sur au moins 1 pour assurer la redondance des données et la haute disponibilité.

• Si la performance de la recherche est une priorité, envisagez d'augmenter le site number_of_replicas. Toutefois, il convient de garder à l'esprit le compromis entre les performances d'écriture et les exigences en matière de stockage.

• Assurez-vous toujours que votre cluster dispose d'une capacité suffisante pour stocker les répliques supplémentaires.

Dans cet article, nous examinerons les raisons d'exclure des champs de l'indexation, comment configurer Elasticsearch pour exclure des champs spécifiques et quelques bonnes pratiques à suivre pour ce faire.

Raisons d'exclure des champs de l'indexation

1. Performance : L'indexation de tous les champs d'un document peut augmenter le temps d'indexation et ralentir les performances de recherche. En excluant les champs qui ne sont pas nécessaires à la recherche ou à l'agrégation, vous pouvez améliorer les performances globales de votre cluster Elasticsearch.

2. Stockage : L'indexation des champs consomme de l'espace de stockage. L'exclusion des champs qui ne sont pas nécessaires à la recherche ou à l'agrégation peut contribuer à réduire les besoins en stockage de votre cluster Elasticsearch.

3. Taille de l'index : La taille d'un index Elasticsearch est directement liée au nombre de champs indexés. En excluant les champs inutiles, vous pouvez réduire la taille de votre index, ce qui permet d'accélérer les performances de recherche et d'indexation.

Configurer Elasticsearch pour exclure des champs

Pour exclure un champ de l'indexation dans Elasticsearch, vous pouvez utiliser la propriété "index" dans le mappage du champ. En définissant la propriété "index" à "false", Elasticsearch n'indexera pas le champ, et il ne sera pas consultable ni disponible pour les agrégations.

Voici un exemple d'exclusion d'un champ de l'indexation à l'aide du mappage Elasticsearch :

Dans cet exemple, nous créons un nouvel index appelé "my_index" avec un seul champ appelé "field_to_exclude". En définissant la propriété "index" à "false", nous indiquons à Elasticsearch de ne pas indexer ce champ. Le champ reste cependant disponible dans le document source.

Meilleures pratiques pour exclure des champs de l'indexation

1. Analysez vos données : Avant d'exclure des champs de l'indexation, il est essentiel d'analyser vos données et de comprendre quels champs sont nécessaires à la recherche et à l'agrégation. Cela vous aidera à prendre des décisions éclairées sur les champs à exclure.

2. Testez vos modifications : Lorsque vous excluez des champs de l'indexation, il est essentiel de tester vos modifications pour vous assurer que vos fonctionnalités de recherche et d'agrégation fonctionnent toujours comme prévu. Cela peut vous aider à éviter des problèmes inattendus ou des problèmes de performance.

3. Contrôlez les performances : Après avoir exclu des champs de l'indexation, surveillez les performances de votre cluster Elasticsearch pour vous assurer que vos modifications ont eu l'effet escompté. Cela peut vous aider à identifier les optimisations supplémentaires qui pourraient être nécessaires.

4. Utiliser le filtrage à la source : Si vous avez besoin de stocker un champ dans Elasticsearch mais que vous ne souhaitez pas qu'il soit consultable ou disponible pour les agrégations, envisagez d'utiliser le filtrage des sources. Cela vous permet de stocker le champ dans le champ _source mais de l'exclure de l'index.

Conclusion

L'exclusion de champs de l'indexation dans Elasticsearch peut contribuer à améliorer les performances, à réduire les coûts de stockage et à minimiser la taille globale de votre index. En analysant soigneusement vos données et en comprenant quels champs sont nécessaires à la recherche et à l'agrégation, vous pouvez prendre des décisions éclairées sur les champs à exclure. Testez toujours vos modifications et surveillez les performances de votre cluster Elasticsearch pour vous assurer que vos optimisations ont l'effet escompté.

Méthode 1 : Utilisation de l'API de mise à jour

API Update vous permet de mettre à jour un document en fournissant un script qui modifie la source du document. Vous pouvez utiliser cette API pour supprimer un champ d'un document en lui attribuant la valeur null. Voici un guide étape par étape pour y parvenir :

1. Identifiez l'index, le type de document (si vous utilisez Elasticsearch 6.x ou une version antérieure) et l'ID du document que vous souhaitez mettre à jour.

2. Utilisez l'API de mise à jour avec un script qui définit le champ comme nul ou, mieux encore, le supprime du document source. L'exemple suivant montre comment supprimer le champ "field_to_delete" d'un document dont l'ID est "1" dans l'index "my_index" :

3. Exécuter la demande. En cas de succès, Elasticsearch renvoie une réponse indiquant que le document a été mis à jour.

Note : Cette méthode ne supprime le champ que du document spécifié. Le champ existera toujours dans la cartographie et dans les autres documents de l'index.

Méthode 2 : Réindexation avec une source modifiée

Si vous souhaitez supprimer un champ de tous les documents d’un index, vous pouvez utiliser l’API Reindex pour créer un nouvel index avec la source modifiée. Voici comment procéder :

1. Créez un nouvel index avec les mêmes paramètres et mappages que l'index original. Vous pouvez utiliser l'API Get Index pour récupérer les paramètres et les mappages de l'index original.

2. Utilisez l'API Reindex pour copier les documents de l'index original vers le nouvel index, tout en supprimant le champ de la source. L'exemple suivant montre comment supprimer le champ "field_to_delete" de tous les documents de l'index "my_index" :

3. Vérifier que le nouvel index contient les documents corrects avec le champ supprimé.

4. Si tout semble correct, vous pouvez supprimer l'index original et, si nécessaire, ajouter un alias au nouvel index portant le nom de l'index original.

Méthode 3 : Mise à jour du mapping et réindexation

Si vous souhaitez supprimer un champ du mappage et de tous les documents d'un index, vous pouvez mettre à jour le mappage, puis réindexer les documents. Voici comment procéder :

1. Créez un nouvel index avec les mêmes paramètres que l'index original.

2. Récupérer les mappings de l'index original à l'aide de l'API "Get Mapping".

3. Modifiez les correspondances en supprimant le champ que vous souhaitez supprimer.

4. Appliquez les mappages modifiés au nouvel index à l'aide de l'API Put Mapping.

5. Utilisez l'API de réindexation pour copier les documents de l'index d'origine vers le nouvel index, comme décrit dans la méthode 2.

6. Vérifiez que le nouvel index contient les documents corrects avec le champ supprimé et que le champ n'est pas présent dans le mappage.

7. Si tout semble en ordre, vous pouvez supprimer l’index original et, si nécessaire, ajouter un alias au nouvel index avec le nom de l’index original.

Conclusion

Dans cet article, nous avons abordé trois méthodes pour supprimer un champ d'un document dans Elasticsearch : l'utilisation de l'API de mise à jour, la réindexation avec une source modifiée et la mise à jour du mappage et la réindexation. Chaque méthode a ses propres cas d'utilisation et ses propres compromis, choisissez donc celle qui répond le mieux à vos besoins. N'oubliez jamais de tester vos modifications et de vérifier les résultats avant de les appliquer aux environnements de production.

Mécanismes de notation dans Elasticsearch

Elasticsearch utilise par défaut un modèle de notation appelé Practical Scoring Function (BM25). Ce modèle est basé sur la théorie probabiliste de la recherche d'informations et prend en compte des facteurs tels que la fréquence des termes, la fréquence inverse des documents et la normalisation de la longueur des champs. Examinons brièvement ces facteurs :

1. Fréquence des termes (TF) : Elle représente le nombre de fois qu'un terme apparaît dans un document. Une fréquence de terme plus élevée indique une relation plus forte entre le terme et le document.

2. Fréquence inverse des documents (IDF) : Ce facteur mesure l'importance d'un terme dans l'ensemble de la collection de documents. Un terme qui apparaît dans de nombreux documents est considéré comme moins important, tandis qu'un terme qui apparaît dans moins de documents est considéré comme plus important.

3. Normalisation de la longueur du champ: Ce facteur tient compte de la longueur du champ dans lequel le terme apparaît. Les champs plus courts ont plus de poids, car le terme est considéré comme plus significatif dans un champ plus court.

Utiliser l'API Expliciter

L'API Explain d'Elasticsearch est un outil précieux pour comprendre le processus de notation. Il fournit une explication détaillée de la manière dont la note d'un document spécifique a été calculée. Pour utiliser l'API Expliciter, vous devez envoyer une requête GET au point de terminaison suivant :

Dans le corps de la demande, vous devez indiquer la requête pour laquelle vous voulez comprendre la notation. En voici un exemple :

La réponse de l'API Expliciter comprendra une ventilation détaillée du processus de notation, y compris les facteurs individuels (TF, IDF et normalisation de la longueur de champ) et leurs contributions à la note finale. Voici un exemple de réponse :

Dans cet exemple, la réponse montre que le score de 1,2 est un produit de la valeur IDF (2,2) et de la valeur tfNorm (0,5). L'explication détaillée permet de comprendre les facteurs contribuant à la note et peut être utile pour affiner la pertinence de la recherche.

Conclusion

La notation Elasticsearch est un aspect essentiel de la fourniture de résultats de recherche pertinents. En comprenant les mécanismes de notation et en utilisant l'API Explain, vous pouvez obtenir des informations sur les facteurs affectant les résultats de recherche et optimiser vos requêtes de recherche pour une meilleure pertinence et de meilleures performances.

• Les définitions de mappage spécifient le schéma de données.

• Les paramètres définissent la taille du groupe et les taux de rafraîchissement. 

• Les alias sont utilisés pour donner d'autres noms à l'index.

Lorsque nous indexons un document pour la première fois ou que nous créons un index vide à l'aide de l'API Create Index, l'index est créé avec les paramètres par défaut, sans schéma de données et sans alias. Ces valeurs par défaut fonctionnent assez bien dans les environnements de développement et de test, mais il se peut que nous devions personnaliser nos indices pour les environnements de production.

L'utilisation des mappages et des paramètres par défaut en production peut entraîner des performances médiocres en matière d'indexation et de recherche. L'instanciation manuelle des indices est un processus fastidieux et chronophage. Recréer de tels index dans chaque environnement est particulièrement peu pratique si nous disposons d'un schéma de correspondance élaboré ainsi que de paramètres et d'alias personnalisés.

Heureusement, Elasticsearch met à notre disposition un outil permettant d'appliquer automatiquement une configuration prédéfinie lors de la création d'index sous la forme de  modèles d' index.

Modèles d'index

Les modèles d'index nous permettent de créer des index avec une configuration définie par l'utilisateur. Lors de son instanciation, un index peut tirer la configuration de ces modèles, par exemple un nombre déterminé de shards et de réplicas ou des mappages de champs. Un modèle sera défini avec un modèle de nom et une certaine configuration. Si le nom de l'index correspond au modèle de dénomination du modèle, le nouvel index sera créé avec la configuration définie dans le modèle.

Elasticsearch a mis à jour sa fonctionnalité de modèle dans la version 7.8 avec des modèles composables. Cette nouvelle version permet de réutiliser beaucoup plus de modèles d'index, comme le montre cet article.

Types de modèles d’index

Les modèles d'index peuvent être classés en deux catégories :

• Modèles d'index (ou modèles d'index composables): Les modèles d'index composables peuvent exister seuls ou être composés d'un ou de plusieurs modèles de composants (voir la deuxième catégorie).

• Modèles de composants : Le modèle de composant est un modèle réutilisable qui définit la configuration requise. En général, le modèle de composant doit être associé à un modèle d'index. Chaque modèle de composant peut être associé à un ou plusieurs modèles d'index. 

Comme vous pouvez le voir dans l'image ci-dessous, les modèles d'index A et B partagent des modèles de composants (dans ce cas, un seul - le modèle 3) entre eux. Un modèle d'index peut être constitué d'un ou de plusieurs modèles de composants et chacun des modèles de composants peut être associé à un ou plusieurs modèles d'index. Les deux types de modèles peuvent exister seuls, mais les modèles de composants ne sont d'aucune utilité s'ils ne sont pas rattachés à un modèle d'index.

L'idée générale est de développer un catalogue de modèles de composants qu'une organisation peut utiliser pour divers besoins (par exemple, en spécifiant les différents modèles de composants pour des environnements individuels) et de les attacher à divers index via les modèles d'index composables.

Comment créer des modèles composables (index)

Elasticsearch fournit un point de terminaison _index_template pour gérer les modèles d'index. L'utilisateur fournit tous les mappages, paramètres et alias nécessaires ainsi qu'un modèle de nom d'index dans ce modèle. Prenons l'exemple de la création d'un modèle pour une application de microservice, customer-order-service, qui est responsable de la logique de génération des commandes. 

Supposons que nous ayons besoin de créer un modèle pour les commandes des clients, représenté par un motif comportant des caractères génériques : *commandes. Ce modèle est censé contenir certains mappages et paramètres, tels que le champ order_date, ainsi que les numéros de shards et de réplicas.

Tout index qui est associé à ce modèle lors de sa création hérite des configurations définies dans ce modèle. Par exemple, un index black_friday_orders aura le champ order_date, les shards seront fixés à 5 et les réplicas à 2. En outre, tous les index créés à partir de ce modèle héritent également d'un nom d'alias unique ! Créons ce modèle orders_template avec un modèle d'index défini comme *orders et avec un schéma de correspondance consistant en un seul champ oder_date avec un format de date prédéfini dd-MM-yyyy. Le code ci-dessous montre comment créer ce modèle d'index.

Lorsque vous exécutez cette requête dans les DevTools de Kibana, le modèle est créé avec le modèle d'index *orders ainsi que le mappage prédéfini, les paramètres et un alias. L'index_patterns est un tableau de motifs de correspondance ; tout index correspondant à ce motif sera dérivé de la configuration du modèle. Vous pouvez exécuter ce qui suit pour récupérer le modèle persisté qui devrait réitérer ce que nous avons fait :

Il existe également une priorité, un nombre positif, définie lors de la création de l'attribut de modèle défini sur le modèle : chaque modèle est défini avec une priorité de sorte que toute modification conflictuelle provenant de différents modèles sera résolue en utilisant cette valeur, la priorité étant donnée à la valeur de priorité la plus élevée. Nous nous pencherons plus en détail sur la priorité des modèles ci-dessous.

Création d'un index avec le modèle

Maintenant que nous disposons d'un modèle - un schéma directeur pour la création d'index - l'étape suivante consiste à créer un index. Lorsque le nom de l'index correspond au modèle donné, les configurations modèles sont appliquées automatiquement. Pour le prouver, comme le montre le code ci-dessous, créons un tout nouvel index nommé : blackfriday_orders :

Comme le nom de l'index (blackfriday_orders) correspond au modèle de dénomination défini dans le modèle (c'est-à-dire *orders), l'index doit obtenir toute la configuration dérivée du modèle. Récupérons cet index fraîchement créé et vérifions si c'est bien le cas en exécutant le code suivant :

Il doit revenir :

Comme l'indique la réponse, la configuration de blackfriday_orders a été héritée du modèle. Nous pouvons essayer diverses combinaisons d'indices qui hériteront avec succès de la configuration modèle :

Cependant, les indices suivants n'hériteront pas de la configuration car leur nom ne correspond pas au modèle :

Il est important de se rappeler que tous les indices dérivés d'un modèle ont le même alias - all_orders - dans ce cas. L'avantage d'un tel alias est qu'il permet d'effectuer des requêtes sur cet alias unique plutôt que sur plusieurs indices.

Si nous créons un modèle pour les *commandes, tout index correspondant est censé adopter la configuration du modèle. En général, sciemment ou non, les équipes peuvent créer quelques modèles supplémentaires pour diverses raisons. Cela signifie que le nom de l'index peut parfois correspondre à deux modèles différents ! Elasticsearch doit décider quelles configurations de ces modèles il doit appliquer. Heureusement, ce dilemme peut être résolu en utilisant le modèle de priorité.

Comment créer des modèles de composants

Nous avons appris à connaître les modèles d'index dans la première partie de cet article. La création de modèles avec la configuration intégrée présente quelques inconvénients, notamment le fait que la configuration n'est pas exportable pour d'autres modèles. Si nous souhaitons disposer d'une configuration similaire, par exemple pour les modèles liés aux clients (*customers), nous devrons peut-être recréer l'ensemble du modèle. Cela signifie que nous pouvons en créer des dizaines dans une organisation typique (et vous pouvez en avoir quelques autres en fonction de l'environnement).

Comme nous cherchons toujours à faciliter la réutilisation, Elasticsearch a redessiné les modèles en gardant à l'esprit la réutilisation. Les modèles de composants répondent à cette exigence. Si vous venez d'un milieu DevOps, il est fort probable que vous ayez besoin de créer des indices avec une configuration prédéfinie pour chacun des environnements. Plutôt que d'appliquer manuellement chacune de ces configurations, vous pouvez créer un modèle de composant pour chacun des environnements.

Un modèle de composant n'est rien d'autre qu'un bloc réutilisable de configurations que nous pouvons utiliser pour créer d'autres modèles d'index. Notez que les modèles de composants n'ont aucune valeur s'ils ne sont pas associés à des modèles d'index. Ils sont exposés via un point de terminaison _component_template. Voyons comment tout cela s'articule.

Paramètres dans un modèle d’index

Extrayons les paramètres que nous avons définis dans notre modèle d'index plus tôt et créons un modèle de composant à partir de celui-ci. Le modèle settings_component_template est censé comporter cinq shards primaires avec deux réplicas par shard primaire. La première étape, comme le montre le code ci-dessous, consiste à déclarer et à exécuter un modèle de composant avec cette configuration.

Comme le montre le code ci-dessus, nous utilisons le point de terminaison _component_template pour créer un modèle de composant. Le corps de la demande contient les informations relatives au modèle dans un objet modèle. Le modèle settings_component_template peut désormais être utilisé ailleurs dans les modèles d'index. Une différence notable est que ce modèle ne définit aucun modèle d'index ; il s'agit simplement d'un bloc de code qui configure certaines propriétés pour nous.

Modèle de correspondance

De la même manière, créons un autre modèle. Cette fois, nous allons extraire le schéma de correspondance que nous avons défini précédemment dans les modèles d'index autonomes. Le code ci-dessous illustre le script :

Modèle d'alias

Dans le même ordre d'idées, nous pouvons également avoir un modèle de composant avec les alias - deux alias (all_orders et sales_orders) :

Modèle d'index composable

Maintenant que nous disposons de ces trois modèles de composants, la prochaine étape consiste à les utiliser. Nous pouvons le faire en laissant un modèle d'index pour, par exemple, christmas_orders, l'utiliser :

La balise composed_of est une collection de tous les modèles de composants qui constituent ce modèle. Dans ce cas, nous choisissons les paramètres, les mappings et les alias des modèles de composants. Nous avons également relevé le niveau de priorité afin que ce modèle l'emporte sur tous les autres. Une fois le modèle prêt, tous les indices correspondant au motif *orders hériteront de la configuration de ces trois modèles de composants.

Cela dit, si nous souhaitons créer un nouveau modèle, par exemple clients, avec un seul des modèles existants (settings_component_template) et un modèle alias nouvellement créé (aliases_component_template - voir ci-dessous), nous pouvons le faire à l'aide de :

Le modèle d'index se présente comme suit :

Avez-vous vu que le modèle settings_component_template a été (ré)utilisé dans deux modèles différents ? C'est la force des modèles de composants.

Priorité du modèle d’index

Il est possible que les développeurs créent plusieurs modèles d'index sans tenir compte du stock existant. Il est important de définir une priorité pour chacun de ces modèles afin que celui qui a la priorité la plus élevée soit utilisé. Par exemple, le modèle my_orders_template_1 remplace le modèle my_orders_template_2 dans l'extrait de code suivant :

Lorsque plusieurs modèles correspondent aux index créés, Elasticsearch applique toutes les configurations de tous les modèles correspondants, mais remplace tout ce qui a une priorité plus élevée.

Préséance des modèles

Enfin, vous vous interrogez peut-être sur la préséance des modèles : la configuration définie dans le modèle de composant est-elle prioritaire par rapport à celle définie dans le modèle d'index principal lui-même ? Ou l'inverse ? Il y a des règles à respecter :

• Un index créé avec des configurations explicites a la priorité sur tout le reste - cela signifie que si vous créez un index avec des configurations explicites, ne vous attendez pas à ce qu'elles soient remplacées par les modèles.

• Les anciens modèles (modèles créés avant la version 7.8) ont une priorité inférieure à celle des modèles composables.

Résumé

• Un index contient des mappings, des paramètres et des alias : les mappings définissent le schéma des champs, les paramètres définissent les paramètres de l'index tels que le nombre de shards et de réplicas, et les alias donnent des noms alternatifs à l'index.

• Les modèles permettent de créer des indices avec des configurations prédéfinies. Le fait de nommer un index avec un nom qui correspond au modèle d'index défini dans un modèle spécifique configurera automatiquement cet index conformément au modèle.

• Elasticsearch a introduit les modèles d'index composables dans la version 7.8. Les modèles d'index composables permettent la modularité et le changement de version des modèles.

• Les modèles composables sont constitués d'au moins un modèle de composant.

• Un modèle d'index peut également avoir sa propre configuration.

• Un modèle de composant est un modèle réutilisable avec une configuration prédéfinie, tout comme un modèle d'index composable.

• Toutefois, les modèles de composants sont censés faire partie d'un modèle d'index ; ils sont inutiles s'ils ne sont pas "composés" dans un modèle d'index.

• Les modèles de composants n'ont pas de modèle d'index défini, ce qui est une autre raison pour laquelle ils sont "censés" faire partie d'un modèle d'index.

• Chaque modèle a une priorité - un nombre positif. Plus le nombre est élevé, plus l'application du modèle est prioritaire.

Techniques avancées pour effectuer des recherches sur deux champs

1. Requête multiple

Une requête multiple vous permet de rechercher une seule chaîne de caractères dans plusieurs champs. Ceci est utile lorsque vous souhaitez trouver des documents qui contiennent la chaîne de requête donnée dans l'un ou l'autre des deux champs. Voici un exemple de requête multi-correspondance recherchant le terme "exemple" dans les champs "titre" ou "description" :

2. Requête Bool

Une requête bool vous permet de combiner plusieurs requêtes en utilisant la logique booléenne. Vous pouvez utiliser la clause "devrait" pour rechercher les documents qui correspondent à la requête dans l'un ou l'autre des deux champs. Voici un exemple de requête bool recherchant le terme "exemple" dans les champs "titre" et "description" :

3. Renforcement des champs au moment de la requête

Il peut arriver que vous souhaitiez accorder plus d'importance à un champ qu'à un autre lors de la recherche. Vous pouvez y parvenir en appliquant un facteur d'amplification au champ au moment de la requête. Une valeur de boost plus élevée donne plus de poids au champ, ce qui le rend plus susceptible d'influencer le résultat final de la recherche. Voici un exemple de requête à correspondances multiples avec un facteur d'amplification appliqué au champ "titre" :

Dans cet exemple, le champ "titre" a un facteur d'amplification de 3, ce qui signifie qu'il est trois fois plus important que le champ "description" pour déterminer le score de recherche.

4. Combinaison de requêtes avec différents facteurs d'amplification

Vous pouvez également combiner plusieurs requêtes avec différents facteurs d'augmentation à l'aide d'une requête bool. Cela vous permet d'affiner l'importance de chaque champ dans les résultats de la recherche. Voici un exemple de requête bool avec différents facteurs de boost appliqués aux champs "titre" et "description" :

Dans cet exemple, le champ "titre" a un facteur d'amplification de 3, tandis que le champ "description" a un facteur d'amplification de 1.

Conclusion

La recherche par deux champs dans Elasticsearch peut être réalisée à l'aide de techniques avancées telles que les requêtes à correspondances multiples, les requêtes bool et l'augmentation du nombre de champs au moment de la requête. En combinant ces techniques, vous pouvez créer des résultats de recherche plus précis et plus pertinents pour vos utilisateurs. Expérimentez différentes combinaisons de requêtes et de facteurs de stimulation pour trouver la configuration de recherche optimale pour votre cas d'utilisation spécifique.

Depuis la version 7.11, Elasticsearch définit par défaut automatiquement la taille du tas de la JVM en fonction des rôles et de la mémoire totale d'un nœud. L'utilisation du dimensionnement par défaut est recommandée pour la plupart des environnements de production. Toutefois, si vous souhaitez définir manuellement la taille du tas de votre JVM, vous devez en règle générale définir -Xms et -Xmx sur la MÊME valeur, soit 50% de votre RAM totale disponible, avec un maximum (approximatif) de 31 Go.

Une taille de tas plus importante permet à votre nœud de disposer de plus de mémoire pour les opérations d'indexation et de recherche. Cependant, votre nœud a également besoin de mémoire pour la mise en cache, de sorte que l'utilisation de 50% maintient un équilibre sain entre les deux. Pour cette même raison, en production, vous devez éviter d'utiliser d'autres processus gourmands en mémoire sur le même nœud qu'Elasticsearch.

En règle générale, l'utilisation du tas suit un schéma en dents de scie, oscillant entre 30 et 70% du tas maximum utilisé. En effet, la JVM augmente régulièrement le pourcentage d'utilisation du tas jusqu'à ce que le processus de ramassage des ordures libère à nouveau de la mémoire. Une forte utilisation du tas se produit lorsque le processus de ramassage des ordures n'arrive pas à suivre. Un indicateur d'une utilisation élevée du tas est lorsque le ramasse-miettes est incapable de réduire l'utilisation du tas à environ 30%.

Dans l'image ci-dessus, vous pouvez voir une dent de scie normale du tas de la JVM.

Vous verrez également qu'il existe deux types de ramassage d'ordures, le jeune et l'ancien GC.

Dans une JVM en bonne santé, le ramassage des ordures devrait idéalement répondre aux conditions suivantes :

• Le jeune GC est traité rapidement (dans les 50 ms).

• Le jeune GC n'est pas exécuté fréquemment (environ 10 secondes).

• L'ancienne CG est traitée rapidement (en moins d'une seconde).

• L'ancienne CG n'est pas exécutée fréquemment (une fois toutes les 10 minutes ou plus).

Comment résoudre le problème d'une utilisation trop importante de la mémoire du tas ou d'une performance non optimale de la JVM ?

Plusieurs raisons peuvent expliquer l'augmentation de l'utilisation de la mémoire du tas :

La surexploitation

Veuillez consulter le document sur le surdimensionnement ici.

Grandes tailles d'agrégation

Afin d'éviter des agrégations trop importantes, limitez au maximum le nombre d'agrégats (taille) dans vos requêtes.

Vous pouvez utiliser la journalisation lente des requêtes (slow logs) et la mettre en œuvre sur un index spécifique en procédant comme suit.

Les requêtes qui prennent beaucoup de temps pour donner des résultats sont probablement celles qui consomment beaucoup de ressources.

Taille excessive de l'index en vrac

Si vous envoyez des requêtes volumineuses, cela peut être la cause d'une consommation élevée de la mémoire vive. Essayez de réduire la taille des demandes d'index en vrac.

Questions de cartographie

En particulier, si vous utilisez "fielddata : true", cela peut être un utilisateur majeur de la mémoire vive de votre JVM.

La taille du tas n'est pas correctement définie

La taille du tas peut être définie manuellement par :

Définition de la variable d'environnement :

Édition du fichier jvm.options dans le répertoire de configuration d'Elasticsearch :

Le paramètre de la variable d'environnement est prioritaire sur le paramètre du fichier.

Il est nécessaire de redémarrer le nœud pour que le réglage soit pris en compte.

Le nouveau ratio de la JVM n'est pas correctement défini

Il n'est généralement PAS nécessaire de définir cette valeur, car Elasticsearch le fait par défaut. Ce paramètre définit le ratio de l'espace disponible pour les objets de "nouvelle génération" et d'"ancienne génération" dans la JVM.

Si vous constatez que les anciens GC deviennent très fréquents, vous pouvez essayer de définir spécifiquement cette valeur dans le fichier jvm.options de votre répertoire de configuration Elasticsearch.

Quelles sont les meilleures pratiques pour gérer l'utilisation de la taille du tas et la collecte des déchets de la JVM dans un grand cluster Elasticsearch ?

Les meilleures pratiques pour gérer l'utilisation de la taille du tas et le ramassage des ordures de la JVM dans un grand cluster Elasticsearch consistent à s'assurer que la taille du tas est fixée à un maximum de 50% de la RAM disponible et que les paramètres du ramassage des ordures de la JVM sont optimisés pour le cas d'utilisation spécifique. Il est important de surveiller la taille du tas et les mesures du ramassage des ordures pour s'assurer que le cluster fonctionne de manière optimale. Plus précisément, il est important de surveiller la taille du tas de la JVM, le temps de ramassage des ordures et les pauses de ramassage des ordures. En outre, il est important de surveiller le nombre de cycles de ramassage des ordures et le temps passé à les effectuer. En surveillant ces mesures, il est possible d'identifier tout problème potentiel lié à la taille du tas ou aux paramètres du ramassage des ordures et de prendre des mesures correctives si nécessaire.

L'API _split est souvent plus rapide que l'API _reindex. L'indexation doit être arrêtée avant les deux opérations, sinon les comptes des documents source_index et cible_index seront différents.

Méthode 1 - utilisation de l'API fractionnée

L'API de fractionnement est utilisée pour créer un nouvel index avec le nombre souhaité d'unités primaires en copiant les paramètres et en mappant un index existant. Le nombre désiré de fragments primaires peut être défini lors de la création. Les paramètres suivants doivent être vérifiés avant de mettre en œuvre l'API fractionnée :

1. L'index source doit être en lecture seule. Cela signifie que le processus d'indexation doit être arrêté.

2. Le nombre de groupes primaires dans l'index cible doit être un multiple du nombre de groupes primaires dans l'index source. Par exemple, si l'index source dispose de 5 groupes primaires, les groupes primaires de l'index cible peuvent être définis comme suit : 10, 15, 20, et ainsi de suite.

Remarque : si seul le numéro du fonds primaire doit être modifié, il est préférable d'utiliser l'API de fractionnement, qui est beaucoup plus rapide que l'API de réindexation.

Mise en œuvre de l'API fractionnée

Créer un index de test :

L'index source doit être en lecture seule pour pouvoir être scindé :

Les paramètres et les correspondances seront copiés automatiquement à partir de l'index source :

Vous pouvez vérifier l'état d'avancement avec :

Étant donné que les paramètres et les mappages sont copiés à partir des index source, l'index cible est en lecture seule. Activons l'opération d'écriture pour l'index cible :

Vérifier les index source et cible docs.count avant de supprimer l'index original :

Le nom de l'index et le nom de l'alias ne peuvent pas être identiques. Vous devez supprimer l'index source et ajouter le nom de l'index source comme alias à l'index cible :

Après avoir ajouté l'alias test_split_source à l'index test_split_target, vous devez le tester avec :

Méthode 2 - utilisation de l'API de réindexation

En créant un nouvel index à l'aide de l'API Reindex, il est possible d'indiquer n'importe quel nombre de comptes de tessons primaires. Après la création d'un nouvel index avec le nombre prévu de groupes primaires, toutes les données de l'index source peuvent être réindexées sur ce nouvel index.

Outre les fonctionnalités de l'API fractionnée, les données peuvent être manipulées à l'aide de la ligne de conduite ingest_pipeline dans l'API de réindexation. Avec le pipeline d'ingestion, seuls les champs spécifiés qui correspondent au filtre seront indexés dans l'index cible à l'aide de la requête. Le contenu des données peut être modifié à l'aide d'un script simple, et plusieurs index peuvent être fusionnés en un seul.

Mise en œuvre de l'API de réindexation

Créer un test de réindexation :

Copier les paramètres et les mappages de l'index source :

Créez un index cible avec des paramètres, des mappings et le nombre de tiroirs souhaité :

*Remarque : les paramètres number_of_replicas : 0 et refresh_interval : -1 augmentera la vitesse de réindexation.

Lancer le processus de réindexation. Les paramètres requests_per_second=-1 et slices=auto permettent d'ajuster la vitesse de réindexation.

Vous verrez l'identifiant de la tâche lorsque vous exécuterez l'API de réindexation. Copiez-le et vérifiez avec l'API _tasks :

Mettre à jour les paramètres une fois la réindexation terminée :

Vérifiez les index source et cible docs.count avant de supprimer l'index original, ils doivent être identiques :

Le nom de l'index et le nom de l'alias ne peuvent pas être identiques. Supprimer l'index source et ajouter le nom de l'index source comme alias à l'index cible :

Après avoir ajouté l'alias test_split_source à l'index test_split_target, testez-le en utilisant :

Résumé

Si vous souhaitez augmenter le nombre de tessons primaires d'un index existant, vous devez recréer les paramètres et les correspondances avec un nouvel index. Il existe deux méthodes principales pour ce faire : l'API de réindexation et l'API de scission. L'indexation active doit être arrêtée avant d'utiliser l'une ou l'autre méthode.

Les inconvénients de cette approche sont qu'elle nécessite une certaine duplication du matériel et qu'elle peut créer des difficultés lors du transfert et de la synchronisation de toutes les données.

Il peut également être nécessaire d'effectuer une procédure similaire si vous devez migrer des applications d'un centre de données à un autre.

Dans cet article, nous allons discuter et détailler trois façons de transférer des données entre les clusters Elasticsearch.

Comment migrer des données entre clusters Elasticsearch ?

Il existe trois façons de transférer des données entre les clusters Elasticsearch :

1. Réindexation à partir d'un cluster distant

2. Transfert de données à l'aide d'instantanés

3. Transférer des données avec Logstash

L'utilisation d'instantanés est généralement le moyen le plus rapide et le plus fiable de transférer des données. Toutefois, n'oubliez pas que vous ne pouvez restaurer un instantané que sur un cluster de version égale ou supérieure et jamais avec une différence de plus d'une version majeure. Cela signifie que vous pouvez restaurer un snapshot 6.x sur un cluster 7.x mais pas sur un cluster 8.x.

Si vous avez besoin d'augmenter de plus d'une version majeure, vous devrez réindexer ou utiliser Logstash.

Examinons maintenant en détail chacune des trois options de transfert de données entre clusters Elasticsearch.

1. Réindexation des données d'un cluster distant

Avant de commencer à réindexer, n'oubliez pas que vous devrez configurer les mappages appropriés pour tous les index sur le nouveau cluster. Pour ce faire, vous devez soit créer les index directement avec les mappings appropriés, soit utiliser des modèles d'index.

Réindexation à distance - configuration requise

Pour réindexer à distance, vous devez ajouter la configuration ci-dessous au fichier elasticseearch.yml pour le cluster qui reçoit les données, qui, dans les systèmes Linux, est généralement situé ici : /etc/elasticsearch/elasticsearch.yml. La configuration à ajouter est la suivante :

Si vous utilisez SSL, vous devez ajouter le certificat CA à chaque nœud et inclure ce qui suit dans la commande pour chaque nœud dans elasticsearch.yml :

Vous pouvez également ajouter la ligne ci-dessous à tous les nœuds Elasticsearch afin de désactiver la vérification SSL. Toutefois, cette approche est moins recommandée car elle n'est pas aussi sûre que l'option précédente :

Vous devrez effectuer ces modifications sur chaque nœud et procéder à un redémarrage progressif. Pour plus d'informations sur la manière de procéder, veuillez consulter notre guide.

Commande de réindexation

Après avoir défini l'hôte distant dans le fichier elasticsearch.yml et ajouté les certificats SSL si nécessaire, vous pouvez commencer à réindexer les données avec la commande ci-dessous :

Il peut donc être utile de fixer des valeurs généreuses pour les délais d'attente plutôt que de se fier aux valeurs par défaut.

Examinons maintenant d'autres erreurs courantes que vous pouvez rencontrer lors d'une réindexation à distance.

Erreurs courantes lors de la réindexation à distance

1. La réindexation ne figure pas sur la liste blanche

Si vous rencontrez cette erreur, cela signifie que vous n'avez pas défini l'adresse IP de l'hôte distant ou le nom du nœud DNS dans Elasticsearch comme décrit ci-dessus ou que vous avez oublié de redémarrer les services Elasticsearch.

Pour résoudre ce problème dans le cluster Elasticsearch, vous devez ajouter l'hôte distant à tous les nœuds Elasticsearch et redémarrer les services Elasticsearch.

2. Exception relative au handshake SSL

Cette erreur signifie que vous avez oublié d'ajouter le certificat reindex.ssl.certificate_authorities à elasticsearch.yml comme décrit ci-dessus. Pour l'ajouter :

2. Transfert de données à l'aide d'instantanés

N'oubliez pas, comme indiqué ci-dessus, que vous ne pouvez restaurer un instantané que sur un cluster de version égale ou supérieure et jamais avec une différence de plus d'une version majeure.

Si vous avez besoin d'augmenter de plus d'une version majeure, vous devrez réindexer ou utiliser Logstash.

Les étapes suivantes sont nécessaires pour transférer des données par le biais d'instantanés :

Étape 1. Ajouter le plugin de référentiel au premier cluster Elasticsearch - Afin de transférer des données entre clusters via des snapshots, vous devez vous assurer que le référentiel est accessible à la fois depuis le nouveau et l'ancien cluster. Les référentiels de stockage en nuage tels que AWS, Google et Azure sont généralement idéaux pour cela. Pour prendre des instantanés, veuillez consulter notre guide et suivre les étapes qu'il décrit.

Étape 2. Redémarrer le service Elasticsearch (rolling restart).

Étape 3. Créez un référentiel pour le premier cluster Elasticsearch.

Étape 4 - Ajouter le plugin de référentiel au deuxième cluster Elasticsearch.

Étape 5- Ajouter un référentiel en lecture seule au deuxième cluster Elasticsearch - Vous devrez ajouter un référentiel en répétant les mêmes étapes que celles que vous avez suivies pour créer le premier cluster Elasticsearch.

Remarque importante : lorsque vous connectez le deuxième cluster Elasticsearch au même référentiel AWS S3, vous devez définir le référentiel comme un référentiel en lecture seule :

C'est important parce que vous voulez éviter le risque de mélanger les versions d'Elasticsearch dans le même dépôt d'instantanés.

Étape 6 - Restauration des données vers le deuxième cluster Elasticsearch - Après avoir suivi les étapes ci-dessus, vous pouvez restaurer les données et les transférer vers le nouveau cluster. Veuillez suivre les étapes décrites dans cet article pour restaurer les données dans le nouveau cluster. 

3. Transfert de données à l'aide de Logstash

Avant de commencer à transférer les données avec logstash, n'oubliez pas que vous devrez configurer les mappings appropriés pour tous les index sur le nouveau cluster. Pour ce faire, vous devrez soit créer les index directement, soit utiliser des modèles d'index.

Pour transférer des données entre deux clusters Elasticsearch, vous pouvez configurer un serveur Logstash temporaire et l'utiliser pour transférer vos données entre les deux clusters. Pour les petits clusters, une instance de 2 Go de mémoire vive devrait suffire. Pour les clusters plus importants, vous pouvez utiliser des CPU à quatre cœurs avec 8 Go de RAM.

Pour des conseils sur l'installation de Logstash, voir ici.

Configuration de Logstash pour le transfert de données d'un cluster à l'autre

La configuration de base pour copier un index unique du cluster A vers le cluster B est la suivante :

Pour sécuriser elasticsearch, vous pouvez utiliser la configuration ci-dessous :

Métadonnées de l'index

Les commandes ci-dessus écrivent dans un seul index nommé. Si vous souhaitez transférer plusieurs index et préserver les noms d'index, vous devez ajouter la ligne suivante à la sortie de Logstash :

De même, si vous souhaitez conserver l'identifiant original du document, vous devrez ajouter :

Gardez à l'esprit que la définition de l'ID du document ralentira considérablement le transfert des données, aussi ne conservez-vous l'ID d'origine que si vous en avez besoin.

Synchronisation des mises à jour

Toutes les méthodes décrites ci-dessus prennent un temps relativement long, et il se peut que des données aient été mises à jour dans le cluster d'origine en attendant la fin du processus.

Il existe plusieurs stratégies pour permettre la synchronisation des mises à jour qui ont pu avoir lieu pendant le processus de transfert des données, et vous devriez réfléchir à ces questions avant d'entamer ce processus. Vous devez notamment réfléchir aux points suivants :

• Quelle méthode utilisez-vous pour identifier les données qui ont été mises à jour/ajoutées depuis le début du processus de transfert de données (par exemple, un champ "last_update_time" dans les données) ?

• Quelle méthode pouvez-vous utiliser pour transférer le dernier élément de données ?

• Existe-t-il un risque de duplication des documents ? En général, c'est le cas, à moins que la méthode que vous utilisez ne fixe l'ID du document à une valeur connue lors de la réindexation).

Les différentes méthodes permettant la synchronisation des mises à jour sont décrites ci-dessous.

1. Utilisation des systèmes de file d'attente

Certains systèmes d'ingestion/mise à jour utilisent des files d'attente qui vous permettent de "rejouer" les modifications de données reçues au cours des x derniers jours. Cela peut permettre de synchroniser les modifications effectuées.

2. Réindexation à distance

Répétez le processus de réindexation pour tous les éléments pour lesquels "last_update_time" > a été effectué il y a x jours. Vous pouvez le faire en ajoutant un paramètre "query" à la requête de réindexation.

3. Logstash

Dans l'entrée Logstash, vous pouvez ajouter une requête pour filtrer tous les éléments pour lesquels "last_update_time" > x jours ago. Toutefois, ce processus entraînera des doublons dans les données non chronologiques, à moins que vous n'ayez défini l'identifiant du document.

4. Instantanés

Il n'est pas possible de restaurer une partie seulement d'un index. Vous devez donc utiliser l'une des autres méthodes de transfert de données décrites ci-dessus (ou un script) pour mettre à jour toutes les modifications qui ont eu lieu depuis le processus de transfert de données.

Cependant, la restauration des instantanés est un processus beaucoup plus rapide que la réindexation/Logstash, il est donc possible de suspendre les mises à jour pendant une courte période de temps pendant que les instantanés sont transférés afin d'éviter le problème.