Afin de comprendre le mode de fonctionnement du moteur d’indexation d’Elasticsearch, il est nécessaire d’être familier à tout un nombre de concepts:
Les champs (ou fields) sont les plus petites unités de données. Chaque champ possède un type de donnée et contient une donnée.
Un document est un objet JSON stocké au sein des index d’Elasticsearch. Les documents sont considérés comme étant l’unité de base de stockage (équivalent d’une ligne dans une table d’une base de donnée relationnelle).
Un mapping défini les différents types présents dans un index. Il définit les champs d’un certain type de documents. Ceci correspond à la notion de schéma dans les bases de données relationnelles.
Un index est la plus grosse unité de données dans Elasticsearch. Il représente une partition logique de documents. Ceci est l’équivalent d’une base de données dans le paradigme relationnel.
Un shard est une subdivision d’un index. En effet, Elasticsearch ne restreint pas les index a un nombre maximal de documents. De ce fait, un index peut stocker des données à en saturer la mémoire de la machine hôte. De plus, à partir du moment où l’index est saturé, toute opération d’insertion ne marchera pas sur la BDD. Ainsi, dans le but de palier à ce problème de stockage et de capacité, il est possible de diviser les index horizontalement, en shards. De cette façon les données de l’index sont distribuées sur tous les shards et le noeuds du cluster Elastcisearch, améliorant les performances d’indexation et permettant de bénéficier de la capacité de stockage des différents noeuds du cluster.
Un répliqua est une copie des shards d’un index. Ils permettent de mettre en place une sécurité contre les différents types de failles pouvant affecter les nœuds du cluster d’Elasticsearch.
Un node (nœud) est le composant majeur d’Elasticsearch. Il prend en charge le stockage et l’indexation des données. Il existe différents types de nœuds:
Chaque nœud du cluster doit être identifiable dans le cluster. De ce fait, chaque nœud a un identifiant unique. En vue des ressources consommées par Elasticsearch, il est recommandé, pour un environnement de production, d’avoir un nœud par serveur.
Un cluster est un ensemble de nœuds/machines qui agissent tous dans un but commun (ici, indexer et rechercher les documents). Un cluster peut se voir évoluer avec le temps (ie: des nœuds peuvent joindre et quitter le cluster), pour garder des temps d’indexation et de recherche courts, et une distribution homogène des données, le cluster se réorganise à mesure qu’il évolue.
Comme Logstash, Elasticsearch est configurable au travers de son fichier elasticsearch.yml. Ce fichier de configuration au format yaml se situe dans le répertoire /DATA/monitoring/elasticsearch. À l’inverse de Logstash qui demande a être configuré pour répondre aux besoins de Picasoft, Elasticsearch ne demande que très peu (voir pas du tout) de configuration. Pour le moment seuls la désactivation des fonctionnalités du X-Pack (version payante proposée par Elastic) se trouve dans le fichier de configuration.
De plus, autre la configuration d’Elasticsearch en soi, il est possible de configurer la manière avec laquelle Elasticsearch log ses messages. Ceci est paramétrable au travers du fichier log4j2.properties. En effet, Elasticsearch utilise Log4j pour ses messages de log.
Elasticsearch dispose d’une REST API qui permet aux utilisateurs de gérer leur nodes et leur cluster, tout en pouvant y ajouter, rechercher, supprimer des documents, index etc. En gros, l’API fournie avec Elasticsearch permet de faire tout ce que l’on veut sur notre cluster et nos données. Puisque la documentation Elasticsearch est très complète, il n’est pas nécessaire ici de re-documenter l’API. Le but de cette partie est, à l’inverse, d’exposer quelques commandes de bases qui permettent d’extraire des données utiles du cluster.
_search: Indique que l’on souhaite faire une recherche
* ?pretty=true&q=:: Est une query indiquant que les résultats (objets JSON seront affichés de façon facile a lire, et, que l’on souhaite tous les documents q=: (ou le premier * représente un champ et le deuxième, une valeur. De ce fait on veut les documents de l’index dont n’importe quel champ vaut n’importe quelle valeur (donc tous))).
* Toutes les données du service Traefik (exemple)
<code>
http:<elasticsearchURL>:9200/<index>/_search?pretty=true&q=service:traefik
</code>En général, pour debuguer, on a l’habitude de faire:
http://<elasticsearchURL>:9200/_cat/indices?v
Pour avoir la liste des index, puis, à partir de là, faire des requêtes de recherches en ajustant la partie q=: pour ne voir que certains types de documents
Là encore, les commandes ci-dessus ne sont qu’un infime fragment des possibilités que nous permet l’API d’Elasticsearch. Il est absolument nécessaire de s’y référer pour pouvoir faire des manipulations plus complexes.