Installation de la suite ELK sur une DEBIAN

Bon ça faisait pas mal de temps que je n’avais pas posté un article. Je travaille actuellement sur les moteurs de recherche. Je suis actuellement en train de monter une architecture ELK (ELASTICSEARCH, LOGSTASH, KIBANA) pour pouvoir gérer l’insertion au fil de l’eau ou en BATCH de données dans le moteur de recherche ELASTICSEARCH.

Architecture et composants

L’architecture typique est la suivante :

Screen_Shot_10-29-14_at_04.08_PM.PNG

On y retrouvera les éléments suivants :

Agents (shipper)

C’est un agent LOGSTASH qui prend désormais la place d’un ETL. Dans mon cas, il scanne un répertoire pour la présence et la modification de fichiers et les envoie au moteur de recherche ou au buffer

Buffer ou le Broker

C’est un cache permettant de découpler les envois de fichiers du moteur de recherche. La base NoSQL REDIS est la plus utilisée pour ce rôle

Indexer /Moteur de recherche

J’utilise ELASTICSEARCH pour ceci

Interface graphique

On utilisera le plugin Kibana d’ ELASTICSEARCH

Je décrirai dans cet article l’installation de LOGSTASH et ELASTICSEARCH

Prérequis

Avoir installé un JDK (version 7 minimum)

Installation de LOGSTASH et ELASTICSEARCH

J’utilise les repository décrits sur le site d’elasticsearch

Lancer la commande suivante

Puis dans le fichier /etc/apt/sources.list.d/elasticsearch.list

Lancer les commandes suivantes

Installation de KIBANA

Après avoir téléchargé l’archive, la placer dans le répertoire /var/www

Assigner l’ URL d’elasticsearch

Redémarrer apache ( pas obligatoire, mais ça ne fait pas de mal….)

Enfin on peut tester la connexion au portail KIBANA Screen_Shot_10-30-14_at_09.54_AM.PNG

Références

http://blog.xebia.fr/2013/12/12/logstash-elasticsearch-kibana-s01e02-analyse-orientee-business-de-vos-logs-applicatifs/

http://www.logstashbook.com/

Faire des recherches dans un index SOLR

2561885967_f5f0be5834_n.jpgMe voila avec un index flambant neuf ( ou presque) importé en presque 30 minutes. Je n’ai plus qu’à rechercher. Voici ce qu’on peut faire assez simplement "out of the box":

Via l’interface d’administration

L’interface d’administration possède déjà un outil de recherche assez simple d’utilisation. On renseigne le critère de recherche et on obtient la réponse au format souhaité ( JSON, XML, PYTHON, CSV,…)

backup_sonar036.png

Cette option peut être intéressante pour une interface d’administration

Via une requête REST

J’ai fait un simple appel REST avec JERSEY pour effectuer la même requête. J’ai utilisé le mapping des POJO pour mapper la réponse à mon bean.

On retrouve les mêmes paramètres

La classe SOLRResponse décrit la réponse JSON, Elle est annotée avec JAXB.

J’ai rendu cette réponse générique pour ensuite appliquer ce que l’on veut dans les documents (ex. Classe CustomerResource)

Via l’API SOLRJ

Pré-requis

Ajouter la dépendance solr au projet

Je trouve cette solution beaucoup plus simple à mettre en oeuvre. Elle prend dynamiquement les champs de la réponse ( qui peuvent changer selon les paramètres d’appels ). De plus il n’y a pas besoin de décrire l’enveloppe de la réponse comme en REST.

Import des données dans un index SOLR

3650487959_d5cac67af6_n.jpg[1]

Comme j’ai pu l’indiquer dans mon précédent billet, je me suis mis en tête d’indexer les données issues d’une base clients. J’ai lancé un simple import . Voici le résultat :

backup_sonar035.png

J’ai donc indexé 19288644 clients en 35 minutes .

Si on regarde du coté de l’espace disque, on obtient la taille suivante :

Les temps d’exécution des requêtes sont déjà très satisfaisants sans aucune optimisation.

Premiers pas avec SOLR

Après avoir pas mal touché à Apache Lucene il y a quelques années ce ça ( je vous par le d’un temps que les moins de vingt ans ne peuvent pas connaître…), j’ai décidé de me pencher sur les moteurs de recherche opensource. J’ai donc décidé de me pencher sur SOLR et ElasticSearch. Ces deux projets sont basés sur lucene.

Le cas d’utilisation que je souhaite mettre en œuvre est assez simple pour l’instant : indexer le résultat d’une requête faite dans un SGBD. Celle ci prend énormément de temps ( environ 30 secondes ) et je souhaite avoir un résultat immédiat le tout en REST.

Le cas elasticsearch

J’ai tout d’abord essayé elasticsearch. Ce dernier est le projet qui a le vent en poupe et présente de nombreux sous-projets très intéressants ( logstash, kibana). Le seul moyen d’extraire les données d’un SGBD est le jdbc-river. Ce moyen ne m’a pas trop séduit , il y a pas mal de problèmes liés à la saisie d’une requête complexe. Aussi j’en ai discuté brièvement avec David Pilato ( qui a fait une super présentation sur Kibana) lors du JugSummerCamp . Il m’a confirmé l’extension du scope du projet logstash aux autres sources de données (ex. JDBC). Cette mutation devrait être effective mi 2014. Bref, en attendant j’ai exploré SOLR.

Présentation de SOLR

SOLR est donc un moteur de recherche ( ça vous l’aviez deviné) qui s’appuie sur Apache Lucene ( ça aussi …) . Il présente des fonctionnalités semblables à ElasticSearch. A ce que j’ai pu lire sur le net ici ou , ce dernier est supérieur sur la gestion des recherches distribuées. Je n’aurais pas besoin de cette fonctionnalité dans un premier temps. Les fonctionnalités qui m’intéressent sont les suivantes :

  • Les API JAVA et REST
  • Le facets
  • La mise en avant de certaines recherches
  • Les requêtes geo spatiales
  • La réplication des données

Configuration

Pour mon projet, je me suis basé sur un archetype maven disponible sur le net. Ce dernier crée un exemple de projet qui lance un jetty avec le war de solr

Vous devez également disposer de la distribution de SOLR pour que le livrable soit déployé. C’est la seule solution que j’ai trouvé pour l’instant. Ce n’est pas très élégant, car je préférerai avoir le tout embarqué dans la webapp.

Mon projet s’appelle customer-indexer . Il indexe les données d’une base de clients. Dans le répertoire src/main/resources, j’ai crée un répertoire customers. J’ai copié le contenu du répertoire collection1 présent dans les exemples de la distribution.

J’exposerai ici la configuration indispensable pour mon cas d’étude

le fichier solr.xml

Dans le répertoire src/main/resources/customers/conf, il faut ajouter a minima les fichiers solrconfig.xml schema.xml et data-config.xml.

solrconfig.xml

Les deux premiers sont déjà présents J’ai modifié le premier avec les informations suivantes :

j’ai mis le chemin en dur de la distribution et non le relatif

La configuration de l’élément elevator semblait erronée

J’ai rajouté également le module d’import des données

schema.xml

Ce fichier décrit la structure des documents présents dans l’index du moteur de recherche. On définit les données à indexer, les types de données et les filtres à appliquer (exemple: tout passer en minuscule)

data-config.xml

Dans ce fichier on spécifie les données récupérées de la base de données

Configuration maven

voici le contenu du pom.xml

Démarrage

Dans mon cas il me suffit de lancer la commande

Import des données

On peut le faire soit par un appel REST, soit par la console : Sélectionner la collection puis cliquer sur Data Import

backup_sonar034.png

Conclusion

Pour l’instant j’ai rapidement fait une première indexation de mes données. je suis conscient qu’il y a pas mal d’améliorations à apporter, notamment sur la modélisation de mon index avec les bonnes entités (ex. une entité customer, une entité address,…)

Je verrai le requêtage dans un autre post.