Elasticsearch rejetait les métriques arrivant en retard. Ces rejets ont provoqué un retard dans le pipeline, entraînant davantage de données en retard, ce qui a déclenché encore plus de rejets. Finalement, le pipeline s'est complètement arrêté.

Nous avons dû restaurer les données à partir d'un snapshot, les réindexer et repenser le pipeline d'ingestion pour pouvoir les récupérer.

La cause principale n'était pas la gestion du cycle de vie des index (ILM) elle-même. C'étaient les flux de données temporelles (TSDS) et la manière dont ils imposent des index sous-jacents limités dans le temps.

Les TSDS peuvent réduire les besoins de stockage des métriques de 40 à 70 %, mais les modifications architecturales qui optimisent leur fonctionnement influent également sur l'évolution des index. Ces changements sont importants lors de la conception de politiques ILM ou lorsque vos pipelines d'ingestion sont susceptibles de générer des données arrivant en retard.

RÉSUMÉ

Lors de l'utilisation de TSDS :

• Les index sous-jacents acceptent uniquement les documents compris dans une fenêtre temporelle spécifique.

• Si des données en retard arrivent après qu'un index passe en mode froid ou gelé, Elasticsearch rejette ces documents ou les achemine vers le stockage des échecs, si configuré.

Règle de conception :

Qu'est-ce qu'un flux de données temporelles ?

Un flux de données temporelles (TSDS) est un flux de données spécialisé optimisé pour les données de métriques. Les données sont acheminées de manière à ce que les documents associés soient situés dans les mêmes partitions, optimisant ainsi la requête et la récupération. Voici comment Elasticsearch procède :

Chaque document contient :

• Un horodatage.

• Des champs dimensionnels qui identifient les séries temporelles.

• Des champs de métriques qui représentent les valeurs mesurées.

En voici quelques exemples :

• Utilisation du processeur par hôte.

• Latence des requêtes par service.

• Relevés de température par capteur.

Les dimensions identifient ce que nous voulons mesurer, tandis que les métriques représentent des valeurs qui évoluent au fil du temps.

Dimensions

Les dimensions décrivent l'entité mesurée.

Exemples :

Nous les définissons dans les mappings avec :

Des métriques

Les métriques représentent des valeurs numériques et sont définies comme suit :

Types de métriques courants :

• Jauge : valeurs qui montent et descendent.

• Compteur : valeurs qui augmentent jusqu'à la réinitialisation.

Elastic Agent collecte principalement des métriques et des données de logs, donc même si vous n'avez pas activé d'index TSDS manuellement, il est possible que vous en ayez toujours dans votre cluster.

Le champ _tsid

Elasticsearch génère en interne une valeur _tsid à partir des champs de dimensions. Cela permet d'acheminer les documents de dimensions identiques vers la même partition, ce qui améliore :

• Compression.

• Localité de la requête.

• Performance d'agrégation.

La principale différence : les index sous-jacents à durée déterminée

Les flux de données traditionnels écrivent toujours dans l'index sous-jacent le plus récent, appelé index d'écriture, mais TSDS se comporte différemment.

Chaque index TSDS sous-jacent comporte une fenêtre temporelle définie et n'accepte que les documents dont les valeurs @timestamp se situent dans cette fenêtre :

Lorsqu’un document est indexé, Elasticsearch l’achemine vers l’index sous-jacent responsable de cet horodatage, ce qui signifie que, contrairement aux index traditionnels, un TSDS peut écrire simultanément dans plusieurs index sous-jacents.

Par exemple :

• Données en temps réel → dernier index.

• Données tardives → index plus ancien couvrant cette plage horaire.

Conception pour les données arrivant en retard

Dans la réalité, les pipelines d'ingestion fournissent rarement les métriques dans les délais impartis. Les métriques peuvent être retardées par des pannes de réseau, des accumulations de données en cours de route, l'ingestion par lots et la perte d'appareils en périphérie, qui se reconnectent ensuite et commencent à rattraper leur retard.

Les index traditionnels absorbent discrètement ces retards, ce qui n'est pas le cas des TSDS.

Si l'horodatage d'un document se situe en dehors de la plage des index de support inscriptibles, Elasticsearch le rejette, ce qui signifie que votre politique ILM doit tenir compte des données en retard.

La contrainte critique

Les index sous-jacents doivent rester accessibles en écriture suffisamment longtemps pour accepter les données en retard.

Concrètement :

Étant donné que l'ILM mesure l'âge à partir de la substitution, la règle opérationnelle est la suivante :

Par exemple, si les métriques peuvent arriver jusqu'à six heures en retard, les index doivent rester inscriptibles au moins six heures après la substitution.

L'absence de prise en compte de cette contrainte est exactement ce qui a causé l'échec d'ingestion décrit précédemment. Les données arrivées en retard ont été dirigées vers un index antérieur, qui se trouvait déjà dans le niveau froid et était donc bloqué en écriture.

Gestion des documents rejetés

Lorsqu'un TSDS rejette un document, Elasticsearch renvoie une erreur, indiquant que l'horodatage ne se situe pas dans la plage des index inscriptibles. La façon dont votre pipeline d'ingestion gère cette erreur détermine si vous perdez des données ou si l'ingestion est bloquée.

Le principal mécanisme pour la gestion des documents rejetés est le magasin des échecs.

Stockage des échecs (recommandé dans Elasticsearch 9.1+)

Elasticsearch 9.1 a introduit le magasin des échecs, qui capture automatiquement les documents rejetés. Au lieu de renvoyer des erreurs aux clients, Elasticsearch écrit les échecs de documents dans un index d'échec dédié au sein du flux de données.

Vous pouvez examiner les échecs à l'aide de :

L'utilisation du stockage des échecs empêche les pipelines d'ingestion d'être bloqués par des erreurs de rejet, tout en préservant les données rejetées à des fins d'analyse ou de réindexation.

Surveillance des problèmes de rejet

Les problèmes de retard d'arrivée apparaissent généralement d'abord sous forme d'anomalies d'ingestion. Vous les remarquerez peut-être d'abord comme :

• Des chutes soudaines du taux d'indexation.

• Une forte augmentation du nombre de documents rejetés.

• Un nombre croissant d'entrées de stockage des échecs.

• Incohérences entre les nombres d'entrées et de sorties du pipeline.

Les alertes en fonction de ces signaux permet aux opérateurs de détecter les problèmes avant que les pipelines ne s'arrêtent. Les workflows, les tâches de machine learning et d'autres mécanismes peuvent être utilisés pour automatiser la détection et les notifications.

Checklist de migration pour les TSDS et l'ILM

Si vous migrez un cluster de métriques vers TSDS, introduisez une hiérarchisation ILM ou effectuez une mise à niveau vers une version d'Elasticsearch où les métriques sont TSDS par défaut, consultez d'abord ces éléments.

1. Mesurer la latence d'ingestion

Avant de modifier les politiques ILM, déterminez :

• Le délai d'ingestion normal.

• Le délai maximal en cas d'incident.

• Les retards dus aux pipelines de traitement par lots.

Votre conception ILM doit prendre en compte le délai réaliste maximal.

2. Vérifier les fenêtres temporelles d'index

Vérifiez vos index sous-jacents TSDS :

Recherchez :

• time_series.start_time

• time_series.end_time

Ces limites déterminent quels index peuvent accepter des documents. Comprendre ces délais permet de déterminer la date limite de rejet des données.

3. Dimensionner le niveau hot pour les arrivées tardives

Assurez-vous que les index sous-jacents restent modifiables suffisamment longtemps pour les données en retard.

Règle opérationnelle :

• warm_min_age > rollover_max_age + maximum_expected_lateness

N'oubliez pas que les index doivent rester accessibles en écriture pendant au moins six heures si les métriques peuvent arriver avec six heures de retard.

4. Décider comment traiter les documents rejetés

Choisissez une stratégie avant d'activer TSDS :

• Magasin des échecs (recommandé dans Elasticsearch 9.1+).

• File d'attente des messages Logstash non distribuables.

• Index de repli pour les arrivées tardives.

• Accepter une perte de données limitée.

5. Monitorer l'intégrité de l'ingestion

Ajoutez des alertes pour :

• Le taux d'indexation chute.

• Documents refusés.

• Croissance du magasin des échecs.

• Incohérences entre les entrées et les sorties du pipeline.

Les problèmes de données tardives apparaissent souvent d'abord sous forme d'anomalies d'ingestion.

Résumé

Les flux de données temporelles apportent des améliorations majeures en termes de stockage et de performances pour les charges de travail des métriques, mais ils introduisent un changement architectural important : les index sous-jacents sont limités dans le temps, ce qui affecte le comportement de l'ILM.

Lors de l'utilisation de TSDS :

• Les index doivent rester inscriptibles suffisamment longtemps pour accepter les données différées.

• Les pipelines d'ingestion doivent gérer les documents rejetés de manière sécurisée.

La règle essentielle à retenir est la suivante :

Si vous concevez les politiques ILM en tenant compte de cette contrainte, TSDS fonctionne de manière optimale pour les charges de travail de métriques.

En revanche, si vous ignorez cette règle, votre pipeline d'ingestion risque de découvrir ces limites temporelles à ses dépens.

Traditionnellement, la gestion des robots d'indexation était un processus manuel et sujet aux erreurs. Il s'agissait de modifier les configurations directement dans l'interface utilisateur et de se débattre avec le clonage des configurations de crawl, le retour en arrière, la gestion des versions, etc. Traiter les configurations des robots comme du code résout ce problème en offrant les mêmes avantages que ceux que nous attendons du développement de logiciels : répétabilité, traçabilité et automatisation.

Ce flux de travail facilite l'intégration de l'Open Web Crawler dans votre pipeline CI/CD pour les retours en arrière, les sauvegardes et les migrations, tâches qui étaient beaucoup plus délicates avec les Elastic Crawlers précédents, tels que l'Elastic Web Crawler ou l'App Search Crawler.

Dans cet article, nous allons apprendre à.. :

• Gérer nos configurations de crawl en utilisant GitHub

• Disposer d'une installation locale pour tester les pipelines avant de les déployer

• Créer une configuration de production pour exécuter le robot d'exploration avec de nouveaux paramètres à chaque fois que nous apportons des modifications à notre branche principale.

Vous pouvez trouver le dépôt du projet ici. Pour l'instant, j'utilise Elasticsearch 9.1.3 et Open Web Crawler 0.4.2.

Produits requis

• Bureau Docker

• Instance Elasticsearch

• Machine virtuelle avec accès SSH (par exemple, AWS EC2) et Docker installé.

Étapes

1. Structure des dossiers

2. Configuration du robot

3. Fichier Docker-compose (environnement local)

4. Actions Github

5. Tests au niveau local

6. Déploiement vers prod

7. Modifications et redéploiement

Structure des dossiers

Pour ce projet, nous aurons la structure de fichier suivante :

Configuration du robot

Sous crawler-config.yml,, nous mettrons les éléments suivants :

Il s'agit d'une recherche à partir de https://web-scraping.dev/products, un site fictif pour les produits. Nous ne parcourrons que les trois premières pages du produit. Le paramètre max_crawl_depth empêchera le robot d'exploration de découvrir d'autres pages que celles définies comme seed_urls en n'ouvrant pas les liens qu'elles contiennent.

Elasticsearch host et api_key seront alimentés dynamiquement en fonction de l'environnement dans lequel nous exécutons le script.

Fichier Docker-compose (environnement local)

Pour le site local docker-compose.yml,, nous allons déployer le crawler et un seul cluster Elasticsearch + Kibana, de sorte que nous puissions facilement visualiser nos résultats de crawling avant de les déployer en production.

Notez que le crawler attend qu'Elasticsearch soit prêt à fonctionner.

Actions Github

Nous devons maintenant créer une action GitHub qui copiera les nouveaux paramètres et exécutera le crawler dans notre machine virtuelle à chaque poussée vers main. Ainsi, nous disposons toujours de la dernière configuration déployée, sans avoir à entrer manuellement dans la machine virtuelle pour mettre à jour les fichiers et exécuter le crawler. Nous allons utiliser AWS EC2 comme fournisseur de machines virtuelles.

La première étape consiste à ajouter l'hôte (VM_HOST), l'utilisateur de la machine (VM_USER), la clé RSA SSH (VM_KEY), l'hôte Elasticsearch (ES_HOST) et la clé API Elasticsearch (ES_API_KEY) aux secrets d'action GitHub :

De cette manière, l'action pourra accéder à notre serveur pour copier les nouveaux fichiers et exécuter le crawl.

Maintenant, créons notre fichier .github/workflows/deploy.yml:

Cette action exécutera les étapes suivantes à chaque fois que des modifications seront apportées au fichier de configuration du crawler :

1. Renseigner l'hôte Elasticsearch et la clé API dans la configuration yml

2. Copier le dossier config sur notre VM

3. Se connecter via SSH à notre VM

4. Exécuter le crawl avec la configuration que nous venons de copier depuis le repo

Tests au niveau local

Pour tester notre crawler localement, nous avons créé un script bash qui remplit l'hôte Elasticsearch avec l'hôte local de Docker et démarre un crawl. Vous pouvez lancer ./local.sh pour l'exécuter.

Regardons Kibana DevTools pour confirmer que le site web-crawler-index a été correctement renseigné :

Déploiement vers prod

Nous sommes maintenant prêts à pousser vers la branche principale, ce qui déploiera le crawler dans votre machine virtuelle et commencera à envoyer des logs à votre instance Serverless Elasticsearch.

Cela déclenchera l'action GitHub, qui exécutera le script de déploiement dans la machine virtuelle et commencera l'exploration.

Vous pouvez confirmer que l'action a été exécutée en allant sur le dépôt GitHub et en visitant l'onglet "Actions" :

Modifications et redéploiement

Vous avez peut-être remarqué que le site price de chaque produit fait partie du champ "body" du document. L'idéal serait de stocker le prix dans un champ distinct afin de pouvoir utiliser des filtres.

Ajoutons cette modification au fichier crawler.yml afin d'utiliser des règles d'extraction pour extraire le prix de la classe CSS product-price:

Nous constatons également que le prix comprend un signe de dollar ($), que nous devons supprimer si nous voulons exécuter des requêtes de plage. Nous pouvons utiliser un pipeline d'acquisition pour cela. Notez que nous y faisons référence dans notre nouveau fichier de configuration du crawler ci-dessus :

Nous pouvons exécuter cette commande dans notre cluster Elasticsearch de production. Pour celui de développement, comme il est éphémère, nous pouvons intégrer la création du pipeline dans le fichier docker-compose.yml en ajoutant le service suivant. Notez que nous avons également ajouté un depends_on au service crawler afin qu'il démarre après la création réussie du pipeline.

Exécutons maintenant `./local.sh` pour voir les changements localement :

C'est très bien ! Poussons maintenant la modification :

Pour confirmer que tout fonctionne, vous pouvez vérifier votre Kibana de production, qui devrait refléter les changements et afficher le prix comme un nouveau champ sans le signe du dollar.

Conclusion

Elastic Open Web Crawler vous permet de gérer votre crawler en tant que code, ce qui signifie que vous pouvez automatiser l'ensemble du pipeline - du développement au déploiement - et ajouter des environnements locaux éphémères et des tests sur les données explorées de manière programmatique, pour ne citer que quelques exemples.

Vous êtes invités à cloner le dépôt officiel et à commencer à indexer vos propres données à l'aide de ce flux de travail. Vous pouvez également lire cet article pour apprendre comment effectuer une recherche sémantique sur les index produits par le crawler.

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

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

3. Affichage des sous-champs

4. Synthetic _source

5. Champs d'exécution

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. L'API _search vous offre plusieurs moyens de contrôler les champs renvoyés ; les deux principaux sont les suivants :

1. _source: Le champ _source contient le corps du document JSON original tel qu'il a été indexé, y compris les modifications apportées par les pipelines d'ingestion ou les étapes de prétraitement. Pour afficher des champs spécifiques du document source, il faut mettre en œuvre le filtrage de la source, comme nous le verrons ci-dessous.

2. fields: Le paramètre fields vous permet d'extraire des champs spécifiques de vos documents lors d'une recherche, sur la base du mappage de l'index. Contrairement à _source, fields peut également renvoyer des valeurs provenant de champs stockés, de valeurs documentaires ou de champs d'exécution sans faire référence à _source, bien que pour les champs standard sans valeurs documentaires ou paramètres stockés, il se réfère à _source. Cela peut apporter de nombreux avantages, notamment en termes de performances, comme nous le verrons ci-dessous.

Utilisation du champ _source

Par défaut, l'API _search renvoie le champ _source, qui contient le document JSON original qui a été indexé. Pour afficher des champs spécifiques, vous pouvez ajouter des filtres dans le paramètre _source de la demande de recherche ; c'est ce qu'on appelle le filtrage à la source.

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.

Si vous avez besoin d'encore plus de contrôle, vous pouvez utiliser les propriétés includes et excludes de l'objet _source. Par exemple, la requête ci-dessous renvoie le champ de premier niveau title et tous les sous-champs de author à l'exception de author.description.

Dans cet exemple, nous utilisons le modèle author.* pour récupérer tous les sous-champs directs de l'objet author . Nous excluons ensuite explicitement author.description afin que seuls les autres champs relatifs à l'auteur soient renvoyés. Notez que cela n'améliore pas les performances, puisqu'il faut toujours charger et analyser la source JSON, mais cela permet de réduire la taille de la réponse envoyée sur le réseau.

Utilisation du paramètre champs

Vous pouvez utiliser le paramètre fields pour filtrer les champs renvoyés dans la réponse de recherche. L'utilisation de fields par rapport à _source présente plusieurs avantages, notamment

• Amélioration des performances : fields peut renvoyer des valeurs directement à partir de champs stockés ou de valeurs de documents sans avoir à charger l'intégralité du site _source, ce qui réduit la taille de la charge utile de la réponse.

• Sortie formatée : Pour les champs standard, fields peut se référer à _source pour récupérer les valeurs, mais il s'appuie sur le mappage de l'index pour formater correctement la sortie, comme les dates formatées, afin de les rendre cohérentes avec ce qui est utilisé pour les agrégations et les tris.

• Accès aux champs d'exécution : fields peut renvoyer des champs d'exécution qui n'existent pas sur le site original _source.

• D'autres avantages peuvent être trouvés ici.

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

Dans la requête ci-dessus, nous attribuons la valeur false au champ _source afin de ne pas renvoyer le document source. Cela peut réduire considérablement la taille de la charge utile de la réponse, mais n'oubliez pas que cela ne fonctionne que si les champs title et author sont de type keyword , pour lesquels doc_values est activé par défaut. Si le champ n'a pas été activé par doc_values et que _source a été défini sur false, Elasticsearch n'aura aucun moyen de les récupérer et ils seront ignorés dans la réponse.

Il est important de noter que la réponse fields renvoie toujours un tableau de valeurs pour chaque champ, même s'il n'y a qu'une seule valeur. Cela est dû au fait qu'Elasticsearch n'a pas de type de tableau dédié, et que tout champ peut avoir plusieurs valeurs. Pour plus d'informations sur les tableaux dans Elasticsearch, cliquez ici.

Autres moyens d'extraire des champs

Bien que l'extraction de champs à l'aide de _source ou fields soit la méthode recommandée, il existe d'autres méthodes pour des cas d'utilisation spécifiques, comme par exemple :

Champs de valeur du document : Si vous souhaitez éviter _source, vous pouvez effectuer une recherche en utilisant le paramètre docvalue_fields . Doc values stocke les mêmes valeurs de champ que _source mais dans une structure de données sur disque, optimisée pour les tris et les agrégations.

Comme il s'agit d'une valeur distincte des valeurs stockées sur _source, vous pouvez demander des champs spécifiques sans avoir à charger l'ensemble du site _source. Cette option est utile si vous interrogez des documents volumineux, mais que vous n'avez besoin que de quelques petits champs prenant en charge des valeurs de documents. Un autre cas d'utilisation de docvalue_fields est celui où vous souhaitez utiliser un formatage personnalisé pour les champs date et numeric, comme nous le verrons dans l'exemple ci-dessous.

Notez que cela ne fonctionne que pour les champs pour lesquels vous avez activé doc_values ou pour les types de champs pour lesquels cette option est activée par défaut, tels que keyword, date, les types numériques et boolean, et non pour text ou annotated_text.

Dans cet exemple, nous utilisons le paramètre docvalue_fields pour récupérer les champs title, author et published sans charger le document _source complet :

Lorsque cette requête est exécutée, Elasticsearch récupère les valeurs directement à partir de son magasin en colonnes sur disque au lieu de référencer le site _source pour chaque document. Le champ published est retourné avec le format epoch_millis au lieu du format par défaut, grâce au paramètre format fourni dans la requête.

Champs stockés : Si vous avez explicitement marqué des champs spécifiques comme étant stockés dans le mappage, vous pouvez utiliser le paramètre stored_fields pour filtrer ces champs. C'est utile si vous voulez des réponses légères avec seulement ces champs spécifiques ou pour les champs que vous avez délibérément stockés pour les retrouver plus tard. Il est stocké séparément de _source, de sorte que cette méthode est également utile pour éviter de devoir charger _source.

Il est important de noter que cette option est désactivée par défaut et qu'elle n'est généralement pas recommandée. Utilisez plutôt le filtrage des sources pour renvoyer certains sous-ensembles du document source original.

Dans l'exemple de requête ci-dessous, nous utilisons le paramètre stored_fields pour récupérer le champ summary, dont la configuration de mappage d'index est "store”: true.

Lorsque cette requête est exécutée, Elasticsearch vérifie si ce champ a été marqué par ”store”: true, s'il ne le trouve pas, il l'ignore complètement.

3. Affichage des sous-champs

Si votre index contient des sous-champs, vous pouvez utiliser la notation point pour spécifier le chemin d'accès au champ dans le paramètre fields. Notez que les sous-champs sont différents du type de champ imbriqué. Par exemple, si vous avez un sous-champ 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.

4. Synthétique _source

Si vous souhaitez conserver la fonctionnalité de _source tout en économisant de l'espace disque, vous avez la possibilité d'utiliser le site synthétique _source dans votre mappage d'index. Synthetic _source est une fonctionnalité qui permet à Elasticsearch de reconstruire _source à partir de données existantes telles que des champs stockés et des valeurs de documents, même lorsque _source est désactivé. Cela vous permet d'économiser beaucoup d'espace de stockage au prix d'une vitesse légèrement inférieure au moment de l'interrogation, car la reconstruction se fait à la volée. Activez cette fonction en utilisant les valeurs ci-dessous dans vos paramètres d'index :

Parmi les avantages de l'utilisation de la version synthétique de _source , citons : l'affichage complet du document lors de l'utilisation de l'API _search, le filtrage des sources et la compatibilité avec d'autres fonctionnalités et outils tels que Kibana qui s'attendent à ce que _source soit disponible, tout en évitant d'avoir à stocker le document _source dans son intégralité.

5. Champs d'exécution

Les champs d'exécution vous permettent de définir des champs scriptés au moment de la requête ou dans votre mappage d'index sous un bloc d'exécution. Ces champs ne sont jamais indexés, de sorte que l'ajout d'un champ d'exécution n'augmente pas la taille de l'index mais n'apparaîtra jamais dans _source. Les champs d'exécution définis dans le mappage sont persistants et disponibles pour toutes les requêtes, tandis que les champs d'exécution définis au moment de la requête sont temporaires et ne sont disponibles que dans cette requête de recherche.

Le principal avantage de l'utilisation des champs d'exécution est la possibilité d'ajouter des champs aux documents après les avoir ingérés, ce qui simplifie vos décisions en matière de mappage. Les champs d'exécution sont également très utiles pour enrichir vos documents avec des valeurs qui n'existent pas dans le document original mais qui sont générées à l'aide d'un script, comme le formatage d'une chaîne de caractères ou le calcul d'un score.

Il convient également de noter que les champs d'exécution peuvent nuire aux performances, car un script devra être exécuté pour chaque document de l'ensemble des résultats. Pour récupérer un champ d'exécution, vous pouvez également utiliser le paramètre fields de l'API _search.

Conclusion

L'affichage des champs d'un index Elasticsearch peut aller de la simple récupération des valeurs à l'aide du mappage d'index ou de _source, à des méthodes plus avancées utilisant fields, docvalue_fields, ou des champs d'exécution pour un meilleur contrôle et une plus grande efficacité. Il est essentiel de comprendre les compromis entre les différentes méthodes pour optimiser vos expériences de recherche. Qu'il s'agisse d'optimiser les charges utiles, d'enrichir des documents ou d'utiliser le site synthétique _source pour économiser de l'espace de stockage, Elasticsearch vous offre de nombreux outils et fonctionnalités pour trouver les données dont vous avez besoin, de la manière dont vous en avez besoin. Ces techniques peuvent vous aider à comprendre la structure de vos données, à identifier des champs spécifiques et à résoudre des problèmes.

Logstash comprend plusieurs filtres intégrés pour les tâches courantes telles que l'analyse, l'enrichissement et la modification des données. Mais parfois, vous rencontrerez des scénarios qui nécessiteront une logique personnalisée allant au-delà de ce que ces filtres standard peuvent fournir. C'est là qu'intervient le plugin Ruby filter.

Le plugin Ruby filter vous permet d'exécuter du code Ruby personnalisé directement dans votre pipeline Logstash. Lorsque les filtres standard ne suffisent pas, le filtre Ruby vous permet de gérer des transformations de données complexes, de mettre en œuvre une logique commerciale personnalisée ou d'intégrer des systèmes externes.

Dans ce blog, nous allons explorer comment utiliser les filtres Ruby, de l'utilisation basique à l'utilisation avancée.

Quand utiliser le filtre Ruby ?

En tant qu'architecte consultant d'Elastic, je vois souvent des clients utiliser Logstash pour le pipeline de traitement des données, même s'il ne s'agit pas aujourd'hui d'un moteur de traitement des données à la pointe de la technologie. Ils se heurtent souvent aux limites des filtres standard lorsqu'il s'agit de manipuler des données complexes ou d'appliquer une logique personnalisée. Dans ce cas, le filtre Ruby peut aider à surmonter ces difficultés.

Le filtre Ruby est utile lorsque les filtres standard de Logstash ne peuvent pas répondre à vos besoins spécifiques. Voici quelques cas d'utilisation courants :

• Manipulation de données imbriquées en profondeur: Modifier des structures JSON complexes, des tableaux dans des tableaux, ou restructurer dynamiquement des données en fonction de leur contenu.

• Traitement avancé des chaînes de caractères: Analyse et extraction de données structurées à partir de textes non structurés

• Mise en œuvre d'une logique d'entreprise complexe: Créer des transformations personnalisées qui nécessitent une logique conditionnelle, des boucles ou des calculs complexes.

Utilisation de base

Commençons par un exemple simple pour comprendre le fonctionnement du filtre Ruby.

Configuration du filtre Ruby

Lorsque vous créez un pipeline Logstash, vous devez placer le fichier de configuration dans le répertoire /etc/logstash/conf.d. Alternativement, vous pouvez utiliser l'option -f pour spécifier le chemin vers le fichier de configuration lorsque vous démarrez Logstash manuellement, afin que vous puissiez expérimenter vos pipelines facilement.

Le fichier de configuration doit avoir une extension .conf.

Pour utiliser le filtre Ruby, définissez un filtre ruby dans la section filter de votre fichier de configuration du pipeline Logstash (*.conf). Voici un exemple de base :

Ce filtre Ruby en ligne définit une instance de filtre Ruby dans votre configuration Logstash. Le paramètre code fournit le script Ruby en ligne que Logstash exécutera pour chaque événement traité par ce filtre. Dans ce script, il existe une variable event qui représente l'événement lui-même. L'objet événement contient les données originales envoyées à Logstash et tous les champs supplémentaires créés lors des étapes de filtrage de Logstash. Vous pouvez accéder à ces champs via l'API Logstash Event telle que event.get() et event.set(). Dans cet exemple de code, event.set('new_field', 'Hello from Ruby!') attribue à un nouveau champ nommé new_field la valeur de chaîne Hello from Ruby!. Vous pouvez ajouter tout autre code dans ce bloc code si nécessaire.

Notez que cet objet event n'est pas un objet de hachage Ruby habituel, bien qu'il agisse comme un conteneur de données de type clé-valeur. Consultez la documentation officielle pour en savoir plus sur l'API des événements.

Externaliser le script Ruby

Pour les transformations simples, le code Ruby en ligne est pratique. Mais pour une logique complexe ou des fonctions réutilisables, il est recommandé de déplacer le code dans un script Ruby externe. Cela permet d'améliorer la maintenabilité et de conserver une configuration propre du pipeline Logstash.

Tout d'abord, créez un script Ruby et enregistrez-le sous my_ruby_script.rb. Le script doit définir une méthode filter qui traite l'événement. Elle prend en argument un objet événement qui représente l'événement en cours de traitement. La méthode filter doit renvoyer un tableau d'événements à émettre. Pour supprimer l'événement, renvoyer un tableau vide.

Par exemple, le script suivant lit la rubrique message, calcule sa longueur et stocke le résultat dans une nouvelle rubrique appelée message_length.

Ensuite, définissez la configuration du filtre Ruby pour qu'il fasse référence au script à l'aide de l'option path. Cela indique à Logstash de charger et d'exécuter le script externe. Lors de l'utilisation de scripts externes, assurez-vous que le fichier existe et que les autorisations sont correctes.

Maintenant, chaque événement est transmis à la méthode filter dans my_ruby_script.rb et est traité par elle.

Cette approche vous permet de gérer plus efficacement une logique complexe, ce qui facilite les tests, le débogage et la réutilisation de votre code Ruby.

Utilisation avancée

Dans cette section, nous allons explorer quelques exemples avancés d'utilisation du filtre Ruby dans Logstash. Ces exemples montrent comment effectuer des transformations de données, enrichir des événements et mettre en œuvre une logique personnalisée à l'aide de Ruby.

Manipulation de structures de données imbriquées

Un événement Logstash est la structure de données centrale que Logstash traite. Il peut contenir différents champs, y compris des structures de données imbriquées telles que des tableaux et des hachages. Le filtre Ruby permet de manipuler facilement ces structures imbriquées.

Le filtre Ruby peut gérer des structures de données imbriquées, telles que des hachages et des tableaux, ce qui permet de modifier ou d'ajouter des champs dans ces structures. Cette fonction est utile lorsqu'il s'agit de traiter des formats de données complexes tels que JSON.

Cet exemple inclut un objet JSON imbriqué dans les données d'entrée. Le filtre Ruby modifie les données imbriquées en ajoutant une nouvelle paire clé-valeur. Ce type de manipulation des données imbriquées n'est pas possible avec les filtres Logstash standard, ce qui fait du filtre Ruby une option pratique pour les structures de données complexes.

Diviser un événement unique en plusieurs événements

Les filtres Ruby peuvent également être utilisés pour diviser un événement unique en plusieurs événements. Ceci est utile lorsque vous avez un événement unique contenant un tableau d'éléments et que vous souhaitez créer des événements distincts pour chaque élément.

Notez que ni le pipeline d'acquisition d'Elasticsearch ni les processeurs de Beats/Elastic Agent ne prennent en charge le fractionnement des événements. C'est l'un des cas d'utilisation les plus importants pour Logstash.

Avec filtre divisé

Vous pouvez utiliser le filtre split pour diviser un événement en plusieurs événements sur la base d'un champ spécifié. Toutefois, si vous devez effectuer des transformations ou des opérations logiques supplémentaires pendant le fractionnement, vous pouvez utiliser le filtre Ruby en combinaison avec le filtre de fractionnement.

Dans l'exemple suivant, nous avons un flux RSS sous la forme d'une seule ligne de texte XML. Il contient plusieurs éléments <item>. Le filtre Ruby est utilisé pour extraire les éléments <item> du XML et les stocker dans un nouveau champ appelé items. Le filtre de division est ensuite utilisé pour diviser l'événement en plusieurs événements sur la base du champ items.

Le résultat sera le suivant :

Comme vous l'avez peut-être remarqué, le filtre ruby n'est pas indispensable dans ce cas. Le filtre split peut être utilisé pour diviser l'événement en plusieurs événements sur la base du champ items, et le filtre mutate peut être utilisé pour supprimer les champs inutiles. Toutefois, si vous devez effectuer des transformations ou des opérations logiques supplémentaires pendant le fractionnement, vous pouvez utiliser le filtre Ruby.

Utiliser un script Ruby en ligne

Vous pouvez également utiliser un script Ruby en ligne pour diviser un événement unique en plusieurs événements en utilisant la méthode event.clone et la méthode new_event_block variable, telle que new_event_block.call(new_event). Cela vous permet de créer de nouveaux événements basés sur l'événement original tout en préservant ses données.

Voici un exemple d'utilisation du filtre Ruby pour diviser un événement unique en plusieurs événements. L'entrée et la sortie sont les mêmes que dans l'exemple précédent.

Utiliser un script Ruby externe

Vous pouvez également utiliser un script Ruby externe pour diviser un événement unique en plusieurs événements.

Fichier de configuration :

Le script Ruby doit être externalisé en tant que split_event.rb:

N'oubliez pas que la méthode filter doit renvoyer un tableau d'événements. Vous pouvez renvoyer plusieurs événements en clonant un objet événement entrant et en l'ajoutant au tableau, ou vous pouvez renvoyer un seul événement sous la forme d'un tableau à un seul élément.

Cela vous permet de diviser un événement unique en plusieurs événements.

Exécuter des commandes externes et analyser leurs résultats

Le plugin Logstash exec input vous permet d'exécuter des commandes externes et leur sortie sera un événement de Logstash. La sortie de la commande sera stockée dans le champ message de l'événement.

Habituellement, la sortie des commandes système est lisible par l'homme, mais n'est pas structurée en JSON ou dans d'autres formats que Logstash peut facilement analyser. Pour ce faire, vous pouvez utiliser le filtre Ruby pour analyser la sortie et en extraire les informations.

Voici un exemple d'utilisation du plugin d'entrée exec pour exécuter la commande ps -ef, qui répertorie tous les processus en cours d'exécution sur un système de type Unix. La sortie sera analysée par le filtre Ruby afin d'extraire les informations pertinentes sur chaque processus.

Cet exemple utilise le plugin d'entrée exec pour exécuter la commande ps -ef toutes les 60 secondes. Le filtre Ruby traite la sortie, en extrayant les champs pertinents tels que UID, PID, PPID, l'utilisation du CPU (C), l'heure de démarrage (STIME), TTY, le temps total du CPU (TIME), et la commande (CMD) exécutée. Cela fonctionne bien dans mon environnement macOS, mais il se peut que vous deviez ajuster les motifs des expressions rationnelles pour qu'ils correspondent au format de sortie de la commande ps -ef sur votre système.

Utiliser les bibliothèques intégrées

Le plugin de filtrage Ruby vous permet d'utiliser des bibliothèques Ruby intégrées, qui peuvent s'avérer très utiles pour diverses tâches. Par exemple, vous pouvez utiliser la bibliothèque json pour analyser les chaînes JSON ou la bibliothèque date pour manipuler les dates.

Voici un exemple d'utilisation de la bibliothèque json pour analyser une chaîne JSON stockée dans un champ :

Pour éviter d'avoir besoin de la bibliothèque à chaque fois, vous devriez externaliser votre code Ruby afin d'utiliser l'instruction require au début de votre script de filtrage Ruby. Cela chargera la bibliothèque une fois et la rendra disponible pour une utilisation dans votre script.

Pour vérifier quelles sont les bibliothèques disponibles dans votre environnement, vous pouvez dresser la liste des bibliothèques intégrées en exécutant le code suivant dans le filtre Ruby :

Note : Les bibliothèques intégrées ne sont pas officiellement supportées par Logstash, et leur comportement peut changer ou elles peuvent ne pas être disponibles dans les versions futures. Utilisez-les à vos risques et périls.

Conclusion

Le filtre Logstash Ruby vous permet de personnaliser et d'étendre les capacités de vos pipelines Logstash. Dans ce billet, nous avons couvert les bases de l'utilisation du filtre Ruby et fourni des exemples d'utilisation avancée.

En tirant parti du filtre Ruby, vous pouvez effectuer des tâches de traitement de données complexes qui nécessitent une logique personnalisée ou des manipulations avancées. Que vous travailliez avec des structures de données imbriquées, que vous fractionniez des événements ou que vous analysiez et convertissiez du texte complexe/non structuré en JSON structuré, le filtre Ruby offre la flexibilité nécessaire pour répondre à vos besoins spécifiques.

Nous espérons que ce guide vous a apporté les connaissances et l'inspiration nécessaires pour explorer tout le potentiel du filtre Logstash Ruby. Bonne lecture !

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.

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é.

• 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.

Dans cet article, nous expliquerons comment configurer Airbyte pour ingérer des données dans Elasticsearch, en abordant les concepts clés, les conditions préalables et l'intégration étape par étape.

Concepts fondamentaux de l'airbyte

L'utilisation d'Airbyte repose sur plusieurs concepts essentiels. Nous en présentons ci-dessous les principales :

• Sources : Définit l'origine des données qui seront extraites.

• Destinations : Définit l'endroit où les données seront envoyées et stockées.

• Connexions : Configure la relation entre la source et la destination, y compris la fréquence de synchronisation.

Intégration d'Airbyte avec Elasticsearch

Dans cette démonstration, nous allons réaliser une intégration où les données stockées dans un bucket S3 seront migrées vers un index Elasticsearch. Nous allons montrer comment configurer la source (S3) et la destination (Elasticsearch) dans Airbyte.

Produits requis

Pour suivre cette démonstration, les conditions suivantes doivent être remplies :

1. Créez un godet dans AWS, où les fichiers JSON contenant les données seront stockés.

2. Installez Airbyte localement à l'aide de Docker.

3. Créer un cluster Elasticsearch dans Elastic Cloud pour stocker les données ingérées.

Nous détaillons ci-dessous chacune de ces étapes.

Installation d'Airbyte

Airbyte peut être exécuté localement à l'aide de Docker ou dans le nuage, où des coûts sont associés à l'utilisation. Pour cette démonstration, nous utiliserons la version locale avec Docker.

L'installation peut prendre quelques minutes. Après avoir suivi les instructions d'installation, Airbyte sera disponible à l'adresse suivante : http://localhost:8000.

Après s'être connecté, nous pouvons commencer à configurer l'intégration.

Création du seau

Dans cette étape, vous aurez besoin d'un compte AWS pour créer un seau S3. En outre, il est essentiel de définir les autorisations correctes en créant une politique et un utilisateur IAM pour permettre l'accès au seau.

Dans le seau, nous téléchargerons des fichiers JSON contenant différents enregistrements de journaux, qui seront ensuite migrés vers Elasticsearch. Les fichiers journaux ont ce contenu :

Vous trouverez ci-dessous les fichiers chargés dans le seau :

Configuration de l'Elastic Cloud

Pour faciliter la démonstration, nous utiliserons Elastic Cloud. Si vous n'avez pas encore de compte, vous pouvez créer un compte d'essai gratuit ici : Enregistrement Elastic Cloud.

Après avoir configuré le déploiement dans Elastic Cloud, vous devrez obtenir :

• L'URL du serveur Elasticsearch.

• Un utilisateur pour accéder à Elasticsearch.

Pour obtenir l'URL, allez sur Deployments > My deployment, dans application, trouvez Elasticsearch et cliquez sur 'Copy endpoint'.

Pour créer l'utilisateur, suivez les étapes ci-dessous :

1. Accès à Kibana > Gestion de la pile > Utilisateurs.

2. Créer un nouvel utilisateur avec le rôle de superutilisateur.

3. Remplissez les champs pour créer l'utilisateur.

Maintenant que tout est en place, nous pouvons commencer à configurer les connecteurs dans Airbyte.

Configuration du connecteur source

Dans cette étape, nous allons créer le connecteur source pour S3. Pour ce faire, nous accédons à l'interface Airbyte et sélectionnons l'option Source dans le menu. Ensuite, nous rechercherons le connecteur S3. Nous détaillons ci-dessous les étapes nécessaires à la configuration du connecteur :

1. Accédez à Airbyte et allez dans le menu Sources.

2. Rechercher et sélectionner le connecteur S3.

3. Configurez les paramètres suivants :

   1. Source Name (Nom de la source) : Définir un nom pour la source de données.

   2. Méthode de livraison : Sélectionnez Replicate Records (recommandé pour les données structurées).

   3. Format des données : Choisissez le format JSON.

   4. Stream Name (Nom du flux) : Définir le nom de l'index dans Elasticsearch.

   5. Bucket Name : Saisissez le nom du réservoir dans AWS.

   6. Clé d'accès AWS et clé secrète AWS : Saisissez les informations d'accès.

Cliquez sur Set up source et attendez la validation.

Connecteur de destination de la configuration

Dans cette étape, nous allons configurer le connecteur de destination, qui sera Elasticsearch. Pour ce faire, nous accédons au menu et sélectionnons l'option Destination. Ensuite, nous rechercherons Elasticsearch et cliquerons sur le résultat obtenu. Nous allons maintenant procéder à la configuration de cette connexion :

1. Accédez à Airbyte et allez dans le menu Destinations.

2. Recherchez et sélectionnez le connecteur Elasticsearch.

3. Configurez les paramètres suivants :

   1. Méthode d'authentification : Choisissez Nom d'utilisateur/Mot de passe.

   2. Nom d'utilisateur et mot de passe : utilisez les informations d'identification créées dans Kibana.

   3. Server Endpoint : Collez l'URL copiée depuis Elastic Cloud.

Cliquez sur Configurer la destination et attendez la validation.

Création de la connexion source et de la connexion destination

Une fois la source et la destination créées, la connexion entre elles sera créée, achevant ainsi la création de l'intégration.

Vous trouverez ci-dessous les instructions pour créer la connexion :

1. Dans le menu, allez dans Connexions et cliquez sur Créer une première connexion.

2. Dans l'écran suivant, vous pouvez sélectionner une source existante ou en créer une nouvelle. Comme nous avons déjà créé une source, nous allons sélectionner la source S3.

3. L'étape suivante consiste à sélectionner la destination. Comme nous avons déjà créé le connecteur Elasticsearch, il sera sélectionné pour finaliser la configuration.

Dans l'étape suivante, il sera nécessaire de définir le mode de synchronisation et le schéma qui sera utilisé. Étant donné que seul le schéma d'enregistrement a été créé, il s'agit de la seule option disponible pour la sélection.

4. Nous allons passer à l'étape de la configuration de la connexion. Ici, nous pouvons définir le nom de la connexion et la fréquence d'exécution de l'intégration. La fréquence peut être configurée de trois manières :

• Cron: Exécute les synchronisations en fonction de l'expression cron définie par l'utilisateur (par exemple 0 0 15 * * ?, à 15:00 tous les jours) ;

• Planifié: Exécute les synchronisations à l'intervalle de temps spécifié (par ex. toutes les 24 heures, toutes les 2 heures) ;

• Manuel: Exécuter les synchronisations manuellement.

Pour cette démonstration, nous sélectionnerons l'option Manuel.

Enfin, en cliquant sur Établir la connexion, la connexion entre la source et la destination sera établie.

Synchronisation des données de S3 vers Elasticsearch

Lorsque vous revenez à l'écran Connexions, vous pouvez voir la connexion qui a été créée. Pour exécuter le processus, il suffit de cliquer sur Sync. À partir de ce moment, la migration des données de S3 vers Elasticsearch commencera.

Si tout se passe bien, vous obtiendrez l'état de synchronisation.

Visualisation des données dans Kibana

Nous allons maintenant aller dans Kibana pour analyser les données et vérifier si elles ont été indexées correctement. Dans la section Kibana Discovery, nous allons créer une vue de données appelée logs. Ainsi, nous pourrons explorer les données existant uniquement dans l'index des journaux, qui a été créé après la synchronisation.

Nous pouvons maintenant visualiser les données indexées et les analyser. De cette manière, nous avons validé l'ensemble du flux de migration en utilisant Airbyte, où nous avons chargé les données présentes dans le seau et les avons indexées dans Elasticsearch.

Conclusion : Airbyte & Intégration d'Elasticsearch

Airbyte s'est avéré être un outil efficace pour l'intégration des données, nous permettant de connecter plusieurs sources et destinations de manière automatisée. Dans ce tutoriel, nous avons montré comment ingérer des données d'un bucket S3 vers un index Elasticsearch, en mettant en évidence les principales étapes du processus.

Cette approche facilite l'ingestion de grands volumes de données et permet des analyses au sein d'Elasticsearch, telles que des recherches complexes, des agrégations et des visualisations de données.

Références

Démarrage rapide Airbyte :

https://docs.airbyte.com/using-airbyte/getting-started/oss-quickstart#part-1-install-abctl

Concepts de base :

https://docs.airbyte.com/using-airbyte/core-concepts/

Qu'est-ce que le LlamaIndex ?

LlamaIndex est un cadre qui facilite la création d'agents et de flux de travail alimentés par de grands modèles linguistiques (LLM) pour interagir avec des données spécifiques ou privées. Il permet l'intégration de données provenant de diverses sources (API, PDF, bases de données) avec les LLM, permettant des tâches telles que la recherche, l'extraction d'informations et la génération de réponses contextualisées.

Concepts clés :

• Agents : Assistants intelligents qui utilisent des LLM pour effectuer des tâches, allant de simples réponses à des actions complexes.

• Flux de travail : Processus en plusieurs étapes qui combinent des agents, des connecteurs de données et des outils pour des tâches avancées.

• Augmentation du contexte : Une technique qui enrichit le LLM avec des données externes, en surmontant ses limites de formation.

Intégration deLlamaIndex avec Elasticsearch :

Elasticsearch peut être utilisé de différentes manières avec LlamaIndex :

• Source de données : Utilisez le lecteur Elasticsearch pour extraire les documents.

• Modèle d'encastrement : Encoder les données en vecteurs pour les recherches sémantiques.

• Stockage vectoriel : Utilisez Elasticsearch comme référentiel pour la recherche de documents vectorisés.

• Stockage avancé : Configurez des structures telles que des résumés de documents ou des graphes de connaissances.

Utiliser LlamaIndex et Elasticsearch pour construire une recherche de FAQ

Préparation des données

Nous utiliserons la FAQ du service Elasticsearch comme exemple. Chaque question a été extraite du site web et enregistrée dans un fichier texte individuel. Vous pouvez utiliser n'importe quelle approche pour organiser les données ; dans cet exemple, nous avons choisi d'enregistrer les fichiers localement.

Exemple de fichier :

Après avoir enregistré toutes les questions, le répertoire ressemblera à ceci :

Installation des dépendances

Nous allons mettre en œuvre l'ingestion et la recherche en utilisant le langage Python, la version que j'ai utilisée étant la 3.9. Comme prérequis, il sera nécessaire d'installer les dépendances suivantes :

Elasticsearch et Kibana seront créés avec Docker, configurés via docker-compose.yml pour exécuter la version 8.16.2. Cela facilite la création de l'environnement local.

L'ingestion de documents à l'aide de LlamaIndex

Les documents seront indexés dans Elasticsearch à l'aide de LlamaIndex. Tout d'abord, nous chargeons les fichiers avec SimpleDirectoryReader, qui permet de charger des fichiers à partir d'un répertoire local. Après avoir chargé les documents, nous les indexons à l'aide du VectorStoreIndex.

Les magasins de vecteurs de LlamaIndex sont responsables du stockage et de la gestion des incorporations de documents. LlamaIndex supporte différents types de Vector Stores, et dans ce cas, nous utiliserons Elasticsearch. Dans le StorageContext, nous configurons l'instance Elasticsearch. Le contexte étant local, aucun paramètre supplémentaire n'a été requis. Pour les configurations dans d'autres environnements, se référer à la documentation pour vérifier les paramètres nécessaires : ElasticsearchStore Configuration.

Par défaut, LlamaIndex utilise le modèle OpenAI text-embedding-ada-002 pour générer des embeddings. Toutefois, dans cet exemple, nous utiliserons le modèle text-embedding-3-small. Il est important de noter qu'une clé API OpenAI sera nécessaire pour utiliser le modèle.

Vous trouverez ci-dessous le code complet pour l'ingestion de documents.

Après l'exécution, les documents seront indexés dans l'index faq comme indiqué ci-dessous :

Recherche avec RAG

Pour effectuer des recherches, nous configurons le client ElasticsearchStore, en définissant les champs index_name et es_url avec l'URL d'Elasticsearch. Dans retrieval_strategy, nous avons défini la stratégie AsyncDenseVectorStrategy pour les recherches vectorielles. D'autres stratégies, telles que AsyncBM25Strategy (recherche par mots-clés) et AsyncSparseVectorStrategy (vecteurs épars), sont également disponibles. Plus de détails peuvent être trouvés dans la documentation officielle.

Ensuite, un objet VectorStoreIndex sera créé, où nous configurerons le vector_store en utilisant l'objet ElasticsearchStore. Avec la méthode as_retriever, nous recherchons les documents les plus pertinents pour une requête, en fixant le nombre de résultats renvoyés à 5 par le biais du paramètre similarity_top_k.

L'étape suivante est le GCR. Les résultats de la recherche vectorielle sont incorporés dans une invite formatée pour le LLM, permettant une réponse contextualisée basée sur les informations récupérées.

Dans le PromptTemplate, nous définissons le format de l'invite, qui inclut :

• Contexte ({context_str}) : documents récupérés par le chercheur.

• Query ({query_str}) : la question de l'utilisateur.

• Instructions : lignes directrices permettant au modèle de répondre en fonction du contexte, sans s'appuyer sur des connaissances externes.

Enfin, le LLM traite l'invite et renvoie une réponse précise et contextuelle.

Le code complet se trouve ci-dessous :

Nous pouvons maintenant effectuer notre recherche, par exemple, "Les services Elastic sont gratuits ?" et obtenir une réponse contextualisée basée sur les données de la FAQ elle-même.

Les documents suivants ont été utilisés pour élaborer cette réponse :

Conclusion

En utilisant LlamaIndex, nous avons démontré comment créer un système efficace de recherche de FAQ avec le support d'Elasticsearch comme base de données vectorielle. Les documents sont ingérés et indexés à l'aide d'enchâssements, ce qui permet d'effectuer des recherches vectorielles. Grâce à un PromptTemplate, les résultats de la recherche sont intégrés dans le contexte et envoyés au LLM, qui génère des réponses précises et contextualisées sur la base des documents récupérés.

Ce flux de travail intègre la recherche d'informations et la génération de réponses contextualisées afin de fournir des résultats précis et pertinents.

Références

https://www.elastic.co/guide/en/cloud/current/ec-faq-getting-started.html

https://docs.llamaindex.ai/en/stable/api_reference/readers/elasticsearch/

https://docs.llamaindex.ai/en/stable/module_guides/indexing/vector_store_index/

https://docs.llamaindex.ai/en/stable/examples/query_engine/custom_query_engine/

https://www.elastic.co/search-labs/integrations/llama-index

Apache Airflow est une plateforme conçue pour créer, planifier et contrôler les flux de travail. Il est utilisé pour orchestrer les processus ETL, les pipelines de données et d'autres flux de travail complexes, en offrant flexibilité et évolutivité. Son interface visuelle et ses capacités de suivi en temps réel rendent la gestion des pipelines plus accessible et plus efficace, vous permettant de suivre la progression et les résultats de vos exécutions. Ses quatre principaux piliers sont décrits ci-dessous :

• Dynamique : Les pipelines sont définis en Python, ce qui permet de générer des flux de travail dynamiques et flexibles.

• Extensible : Airflow peut être intégré dans une variété d'environnements, des opérateurs personnalisés peuvent être créés et un code spécifique peut être exécuté selon les besoins.

• Élégant : Les pipelines sont rédigés de manière claire et explicite.

• Évolutif : Son architecture modulaire utilise une file d'attente de messages pour orchestrer un nombre arbitraire de travailleurs.

Dans la pratique, Airflow peut être utilisé dans des scénarios tels que

• Importation de données : Orchestrer l'ingestion quotidienne de données dans une base de données telle qu'Elasticsearch.

• Surveillance des journaux : Gérer la collecte et le traitement des fichiers journaux, qui sont ensuite analysés dans Elasticsearch pour identifier les erreurs ou les anomalies.

• Intégration de sources de données multiples : Combinez des informations provenant de différents systèmes (API, bases de données, fichiers) en une seule couche dans Elasticsearch, ce qui simplifie la recherche et la création de rapports.

Comprendre les DAG (Directed Acyclic Graphs) dans Airflow

Dans Airflow, les flux de travail sont représentés par des DAG (Directed Acyclic Graphs). Un DAG est une structure qui définit la séquence d'exécution des tâches. Les principales caractéristiques des DAG sont les suivantes

• Composition par tâches indépendantes : Chaque tâche représente une unité de travail et est conçue pour être exécutée de manière indépendante.

• Séquencement : L'ordre dans lequel les tâches sont exécutées est explicitement défini dans le DAG.

• Réutilisation : Les DAG sont conçus pour être exécutés de manière répétée, ce qui facilite l'automatisation des processus.

Composants du flux d'air

L'écosystème Airflow est composé de plusieurs éléments qui fonctionnent ensemble pour orchestrer les tâches :

• Ordonnanceur : Responsable de la programmation des DAG et de l'envoi des tâches à exécuter par les travailleurs.

• Exécutant : Il gère l'exécution des tâches et les délègue aux travailleurs.

• Serveur Web : Fournit une interface graphique permettant d'interagir avec les DAG et les tâches.

• Dossier Dags : Dossier dans lequel nous stockons les DAGs écrits en Python.

• Métadonnées : Base de données qui sert de référentiel pour l'outil, utilisée par le planificateur et l'exécuteur pour stocker l'état d'exécution.

Apache Airflow et Elasticsearch

Nous démontrerons l'utilisation d'Apache Airflow et d'Elasticsearch pour orchestrer des tâches et indexer les résultats dans Elasticsearch. L'objectif de cette démonstration est de créer un pipeline de tâches pour mettre à jour les enregistrements dans un index Elasticsearch. Cet index contient une base de données de films, où les utilisateurs peuvent évaluer et attribuer des notes. Imaginons un scénario avec des centaines d'évaluations quotidiennes, il est nécessaire de maintenir l'enregistrement des évaluations à jour. Pour ce faire, un DAG sera développé et exécuté quotidiennement, chargé de récupérer les nouvelles notations consolidées et de mettre à jour les enregistrements dans l'index.

Dans le flux DAG, nous aurons une tâche pour récupérer les classements, suivie d'une tâche pour valider les résultats. Si les données n'existent pas, le DAG sera dirigé vers une tâche d'échec. Sinon, les données seront indexées dans Elasticsearch. L'objectif est de mettre à jour le champ de classement des films dans un index en récupérant les classements par le biais d'une méthode avec le mécanisme responsable du calcul des scores.

Utiliser Apache Airflow et Elasticsearch avec Docker

Pour créer un environnement conteneurisé, nous utiliserons Apache Airflow avec Docker. Suivez les instructions du guide "Running Airflow in Docker" pour configurer Airflow de manière pratique.

En ce qui concerne Elasticsearch, j'utiliserai un cluster sur Elastic Cloud, mais si vous préférez, vous pouvez également configurer Elasticsearch avec Docker. Un index a déjà été créé, contenant un catalogue de films, avec les données des films indexées. Le champ "rating" de ces films sera mis à jour.

Création du DAG

Après l'installation via Docker, une structure de dossiers sera créée, y compris le dossier dags, où nous devons placer nos fichiers DAG pour qu'Airflow les reconnaisse.

Avant cela, nous devons nous assurer que les dépendances nécessaires sont installées. Voici les dépendances pour ce projet :

Nous allons créer le fichier update_ratings_movies.py et commencer à coder les tâches.

Maintenant, importons les bibliothèques nécessaires :

Nous utiliserons ElasticsearchPythonHook, un composant qui simplifie l'intégration entre Airflow et un cluster Elasticsearch en abstrayant la connexion et l'utilisation d'API externes.

Nous définissons ensuite le DAG en précisant ses principaux arguments :

• dag_idle nom du DAG.

• start_date: quand le DAG démarrera.

• schedule: définit la périodicité (quotidienne dans notre cas).

• doc_mdLa documentation : la documentation qui sera importée et affichée dans l'interface Airflow.

Définition des tâches

Définissons maintenant les tâches du DAG. La première tâche consistera à récupérer les données relatives à la classification des films. Nous utiliserons l'opérateur Python avec l'adresse task_id fixée à 'get_movie_ratings'. Le paramètre python_callable appellera la fonction responsable de la recherche des classements.

Ensuite, nous devons vérifier si les résultats sont valables. Pour cela, nous utiliserons une conditionnelle avec un BranchPythonOperator. L'adresse task_id sera 'validate_result', et l'adresse python_callable appellera la fonction de validation. Le paramètre op_args sera utilisé pour transmettre le résultat de la tâche précédente, 'get_movie_ratings', à la fonction de validation.

Si la validation est réussie, nous prendrons les données de la tâche 'get_movie_ratings' et les indexerons dans Elasticsearch. Pour ce faire, nous allons créer une nouvelle tâche, 'index_movie_ratings', qui utilisera l'opérateur Python. Le paramètre op_args transmet les résultats de la tâche 'get_movie_ratings' à la fonction d'indexation.

Si la validation indique un échec, le DAG passe à une tâche de notification d'échec. Dans cet exemple, nous nous contentons d'imprimer un message, mais dans un scénario réel, nous pourrions configurer des alertes pour signaler les défaillances.

Enfin, nous définissons les dépendances des tâches, en veillant à ce qu'elles s'exécutent dans le bon ordre :

Voici maintenant le code complet de notre DAG :

Visualisation de l'exécution du DAG

Dans l'interface Apache Airflow, nous pouvons visualiser l'exécution des DAGs. Il suffit d'aller sur l'onglet "DAGs" et de localiser le DAG que vous avez créé.

Ci-dessous, nous pouvons visualiser les exécutions des tâches et leurs statuts respectifs. En sélectionnant une exécution pour une date spécifique, nous pouvons accéder aux journaux de chaque tâche. Notez que dans la tâche index_movie_ratings, nous pouvons voir les résultats de l'indexation dans l'index, et qu'elle s'est déroulée avec succès.

Dans les autres onglets, il est possible d'accéder à des informations supplémentaires sur les tâches et le GDA, ce qui facilite l'analyse et la résolution des problèmes potentiels.

Conclusion

Dans cet article, nous avons montré comment intégrer Apache Airflow à Elasticsearch pour créer une solution d'ingestion de données. Nous avons montré comment configurer le DAG, définir les tâches responsables de la récupération, de la validation et de l'indexation des données des films, ainsi que contrôler et visualiser l'exécution de ces tâches dans l'interface Airflow.

Cette approche peut être facilement adaptée à différents types de données et de flux de travail, ce qui fait d'Airflow un outil utile pour orchestrer les pipelines de données dans divers scénarios.

Références

Apache AirFlow

https://airflow.apache.org/

Installer Apache Airflow avec Docker

https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html

Elasticsearch Python Hook

https://airflow.apache.org/docs/apache-airflow-providers-elasticsearch/stable/hooks/elasticsearch_python_hook.html

Opérateur Python

https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html

Produits requis

• Docker et Docker Compose : Assurez-vous que Docker et Docker Compose sont installés sur votre machine.

• Python 3.x : Pour exécuter les scripts du producteur et du consommateur.

Introduction à Apache Kafka

Apache Kafka est une plateforme de diffusion en continu distribuée qui permet une évolutivité et une disponibilité élevées, ainsi qu'une tolérance aux pannes. Dans Kafka, la gestion des données s'effectue par le biais des principaux composants :

• Courtier: responsable du stockage et de la distribution des messages entre les producteurs et les consommateurs.

• Zookeeper: gère et coordonne les courtiers Kafka, en contrôlant l'état de la grappe, les chefs de partition et les informations sur les consommateurs.

• Sujets: canaux où les données sont publiées et stockées pour être consommées.

• Consommateurs et producteurs: tandis que les producteurs envoient des données aux thèmes, les consommateurs récupèrent ces données.

Ces composants fonctionnent ensemble pour former l'écosystème Kafka, qui fournit un cadre robuste pour la diffusion de données en continu.

Structure du projet

Pour comprendre le processus d'ingestion des données, nous l'avons divisé en plusieurs étapes :

• Provisionnement de l'infrastructure: mise en place de l'environnement Docker pour prendre en charge Kafka, Elasticsearch et Kibana.

• Création du producteur: mise en œuvre du producteur Kafka, qui envoie des données au sujet des journaux.

• Création du consommateur: développement du consommateur Kafka pour lire et indexer les messages dans Elasticsearch.

• Validation de l'ingestion: vérification et validation des données envoyées et consommées.

Configuration de l'infrastructure avec Docker Compose

Nous avons utilisé Docker Compose pour configurer et gérer les services nécessaires. Vous trouverez ci-dessous le code Docker Compose qui met en place chaque service nécessaire à l'intégration d'Apache Kafka, Elasticsearch et Kibana, en assurant un processus d'ingestion des données.

Vous pouvez accéder au fichier directement depuis le repo GitHub d'Elasticsearch Labs.

Envoi de données avec le producteur Kafka

Le producteur est responsable de l'envoi des messages au sujet des journaux. L'envoi de messages par lots augmente l'efficacité de l'utilisation du réseau et permet d'optimiser les paramètres batch_size et linger_ms, qui contrôlent respectivement la quantité et la latence des lots. La configuration acks='all' garantit que les messages sont stockés durablement, ce qui est essentiel pour les données d'enregistrement importantes.

Lors du démarrage du producteur, les messages sont envoyés par lots au sujet, comme indiqué ci-dessous :

Consommation et indexation des données avec le consommateur Kafka

Le consommateur est conçu pour traiter efficacement les messages, en consommant des lots à partir du sujet des journaux et en les indexant dans Elasticsearch. Avec auto_offset_reset='latest', il s'assure que le consommateur commence à traiter les messages les plus récents, en ignorant les plus anciens, et max_poll_records=10 limite le lot à 10 messages. Avec fetch_max_wait_ms=2000, le consommateur attend jusqu'à 2 secondes pour accumuler suffisamment de messages avant de traiter le lot.

Dans sa boucle principale, le consommateur consomme les messages du journal, traite et indexe chaque lot dans Elasticsearch, assurant ainsi une ingestion continue des données.

Visualisation des données dans Kibana

Avec Kibana, nous pouvons explorer et valider les données ingérées depuis Kafka et indexées dans Elasticsearch. En accédant à Dev Tools dans Kibana, vous pouvez visualiser les messages indexés et confirmer que les données sont conformes aux attentes. Par exemple, si notre producteur Kafka a envoyé 5 lots de 10 messages chacun, nous devrions voir un total de 50 enregistrements dans l'index.

Pour vérifier les données, vous pouvez utiliser la requête suivante dans la section Outils de développement :

Réponse :

En outre, Kibana permet de créer des visualisations et des tableaux de bord qui peuvent rendre l'analyse plus intuitive et interactive. Vous trouverez ci-dessous quelques exemples de tableaux de bord et de visualisations que nous avons créés, qui illustrent les données sous différents formats, améliorant ainsi notre compréhension des informations traitées.

Ingestion de données avec Kafka Connect

Kafka Connect est un service conçu pour faciliter l'intégration entre les sources de données et les destinations (puits), telles que les bases de données ou les systèmes de fichiers. Il fonctionne avec des connecteurs prédéfinis qui gèrent automatiquement les mouvements de données. Dans notre cas, Elasticsearch fait office de puits de données.

En utilisant Kafka Connect, nous pouvons simplifier le processus d'ingestion de données, en éliminant la nécessité d'implémenter manuellement le workflow d'ingestion de données dans Elasticsearch. Avec le connecteur approprié, Kafka Connect permet aux données envoyées à un sujet Kafka d'être directement indexées dans Elasticsearch avec une configuration minimale et sans codage supplémentaire.

Travailler avec Kafka Connect

Pour mettre en œuvre Kafka Connect, nous allons ajouter le service kafka-connect à notre installation Docker Compose. Un élément clé de cette configuration est l'installation du connecteur Elasticsearch, qui se chargera de l'indexation des données.

Après avoir configuré le service et créé le conteneur Kafka Connect, un fichier de configuration pour le connecteur Elasticsearch sera nécessaire. Ce fichier définit des paramètres essentiels tels que

• connection.url: URL de connexion pour Elasticsearch.

• topics: Le sujet Kafka que le connecteur surveillera (dans ce cas, "logs").

• type.name: Type de document dans Elasticsearch (typiquement _doc).

• value.converter: Convertit les messages Kafka au format JSON.

• value.converter.schemas.enable: Spécifie si le schéma doit être inclus.

• schema.ignore et key.ignore: Paramètres permettant d'ignorer les schémas et les clés Kafka lors de l'indexation.

Voici la commande curl pour créer le connecteur Elasticsearch dans Kafka Connect :

Avec cette configuration, Kafka Connect commencera automatiquement à ingérer les données envoyées au sujet "logs" et à les indexer dans Elasticsearch. Cette approche permet d'automatiser entièrement l'ingestion et l'indexation des données sans nécessiter de codage supplémentaire, ce qui simplifie l'ensemble du processus d'intégration.

Conclusion

L'intégration de Kafka et d'Elasticsearch crée un pipeline puissant pour l'ingestion et l'analyse de données en temps réel. Ce guide fournit une approche fondamentale pour construire une architecture d'ingestion de données robuste, avec une visualisation et une analyse transparentes dans Kibana, prête à s'adapter à des exigences plus complexes à l'avenir.

En outre, l'utilisation de Kafka Connect rend l'intégration entre Kafka et Elasticsearch encore plus rationnelle, en éliminant le besoin de code supplémentaire pour traiter et indexer les données. Kafka Connect permet aux données envoyées à un sujet spécifique d'être automatiquement indexées dans Elasticsearch avec une configuration minimale.

Qu'est-ce qu'Apache Camel ?

Apache Camel est un cadre d'intégration open-source qui simplifie la connexion de divers systèmes, permettant aux développeurs de se concentrer sur la logique commerciale sans se préoccuper des complexités de la communication entre les systèmes. Le concept central de Camel est "routes," qui définit le chemin suivi par un message de l'origine à la destination, en incluant éventuellement des étapes intermédiaires telles que des transformations, des validations et des filtrages.

Architecture d'Apache Camel

Camel utilise les composants "" pour se connecter à différents systèmes et protocoles, tels que les bases de données et les services de messagerie, et les points d'extrémité "" pour représenter les points d'entrée et de sortie des messages. Ces concepts offrent une conception modulaire et flexible, facilitant la configuration et la gestion d'intégrations complexes de manière efficace et évolutive.

Utilisation d'Elasticsearch et d'Apache Camel

Nous allons montrer comment configurer une application Java simple qui utilise Apache Camel pour ingérer des données dans un cluster Elasticsearch. Les processus de création, de mise à jour et de suppression de données dans Elasticsearch à l'aide de routes définies dans Apache Camel seront également abordés.

1. Ajout de dépendances

La première étape de la configuration de cette intégration consiste à ajouter les dépendances nécessaires au fichier pom.xml de votre projet. Cela inclut les bibliothèques Apache Camel et Elasticsearch. Nous utiliserons la nouvelle bibliothèque Java API Client, nous devons donc importer le composant camel-elasticsearch et la version doit être la même que celle de la bibliothèque camel-core.

Si vous souhaitez utiliser le Java Low level Rest Client, vous devez utiliser le composant Elasticsearch Low level Rest Client.

2. Configuration et exécution du contexte Camel

La configuration commence par la création d'un nouveau contexte Camel à l'aide de la classe DefaultCamelContext, qui sert de base à la définition et à l'exécution des itinéraires. Ensuite, nous configurons le composant Elasticsearch, qui permettra à Apache Camel d'interagir avec un cluster Elasticsearch. L'instance ESlasticsearchComponent est configurée pour se connecter à l'adresse localhost:9200, qui est l'adresse par défaut d'un cluster Elasticsearch local. Dans le cas d'un environnement nécessitant une authentification, il convient de lire la documentation relative à la configuration du composant et à l'activation de l'authentification de base, appelée ". Configurer le composant et activer l'authentification de base".

Ce composant est ensuite ajouté au contexte Camel, ce qui permet aux routes définies d'utiliser ce composant pour effectuer des opérations dans Elasticsearch.

Ensuite, les itinéraires sont ajoutés au contexte. Nous allons créer des itinéraires pour l'indexation, la mise à jour et la suppression de documents en masse.

3. Configuration des itinéraires Camel

Indexation des données

La première route que nous allons configurer est destinée à l'indexation des données. Nous utiliserons un fichier JSON contenant un catalogue de films. La route sera configurée pour lire le fichier situé à l'adresse src/main/resources/movies.json, désérialiser le contenu JSON en objets Java, puis appliquer une stratégie d'agrégation pour combiner plusieurs messages en un seul, permettant ainsi des opérations par lots dans Elasticsearch. La taille de 500 éléments par message a été configurée, c'est-à-dire que le bulk indexera 500 films à la fois.

Route Elasticsearch Operation Bulk

Le lot de documents sera envoyé au point de terminaison de l'opération en bloc d'Elasticsearch. Cette approche garantit l'efficacité et la rapidité du traitement de grands volumes de données.

Mise à jour des données

La prochaine étape consistera à mettre à jour les documents. Nous avons indexé quelques films dans l'étape précédente et nous allons maintenant créer de nouvelles routes pour rechercher un document par code de référence et mettre à jour le champ "rating".

Nous mettons en place un contexte Camel (DefaultCamelContext), dans lequel un composant Elasticsearch est enregistré et une route personnalisée IngestionRoute est ajoutée. L'opération commence par l'envoi du code du document par le ProducerTemplate, qui lance la route à partir du point de terminaison direct:update-ingestion.

Ensuite, nous avons l'IngestionRoute, qui est le point d'entrée de ce flux. La route effectue plusieurs opérations en pipeline. Tout d'abord, une recherche dans Elasticsearch est effectuée pour localiser le document par code (direct:search-by-id), où le SearchByCodeProcessor assemble la requête sur la base du code. Ensuite, le document récupéré est traité par l'UpdateRatingProcessor, qui convertit le résultat en objets Movie, met à jour la classification du film avec une valeur spécifique et prépare le document mis à jour à renvoyer à Elasticsearch pour la mise à jour.

Le processeur SearchByCodeProcessor a été configuré uniquement pour exécuter la requête de recherche :

Le processeur UpdateRatingProcessor est responsable de la mise à jour du champ "rating".

Suppression des données

Enfin, l'itinéraire de suppression des documents est configuré. Ici, nous allons supprimer un document en utilisant son ID. Dans Elasticsearch, pour supprimer un document, il faut connaître l'identifiant du document, l'index dans lequel le document est stocké et exécuter une requête Delete. Dans Apache Camel, nous effectuerons cette opération en créant une nouvelle route, comme indiqué ci-dessous.

L'itinéraire part du point d'arrivée direct:op-delete, qui sert de point d'entrée. Lorsqu'un document doit être supprimé, son identifiant (_id) est reçu dans le corps du message. La route définit ensuite l'en-tête indexId avec la valeur de cet identifiant en utilisant le simple("${body}"), qui extrait l'_id du corps du message.

Enfin, le message est dirigé vers le point de terminaison spécifié par URI_DELETE_OPERATION, qui se connecte à Elasticsearch pour effectuer l'opération de suppression du document dans l'index correspondant. Maintenant que nous avons créé la route, nous pouvons créer un contexte Camel (DefaultCamelContext), qui est configuré pour inclure le composant Elasticsearch.

Ensuite, la route de suppression, définie par la classe OperationDeleteRoute, est ajoutée au contexte. Une fois le contexte initialisé, une adresse ProducerTemplate est utilisée pour transmettre l'identifiant du document à supprimer à l'adresse direct:op-delete, qui déclenche la procédure de suppression.

Conclusion

L'intégration entre Apache Camel et Elasticsearch permet une ingestion robuste et efficace des données, en tirant parti de la flexibilité de Camel pour définir des itinéraires capables de gérer différents scénarios de manipulation des données, tels que l'indexation, la mise à jour et la suppression. Grâce à cette configuration, vous pouvez orchestrer et automatiser des processus complexes de manière évolutive, en veillant à ce que vos données soient gérées efficacement dans Elasticsearch. Cet exemple montre comment ces outils peuvent être utilisés ensemble pour créer une solution efficace et adaptable pour l'ingestion de données.

Références

• Apache Camel

• Architecture d'Apache Camel

• Agrégation Apache Camel

• Composant du dossier

• Composant Elasticsearch