Elasticsearch on Java & Moi

Bonnes pratiques de logging

Sun, 03 Jan 2021 11:44:26 +0000

Publier en 2021 un article sur les logs n’est pas très novateur ; je vous l’accorde. Le logging est une pratique vieille comme l’informatique, ou presque. C’est une pratique universelle qu’on retrouve quel que soit le langage de programmation et quel que soit le type d’application. Pour autant, elle est survolée en fac et en école d’ingénieur. Les dévs apprennent bien souvent à logger sur le tas, en fonction de leurs besoins et de ce qui est déjà mis en place sur leur application. Rares sont également les entreprises mettant à disposition des normes et des bonnes pratiques en termes de traces applicatives.

Dans cet article, je ne vous expliquerai pas comment utiliser SLF4J, Logback, Log4j 2 ou la controversée API de Logging du langage Java. C’est un prérequis que bon nombre d’entre vous connaissent déjà. Beaucoup de ressources existent à ce sujet, en commençant par leurs documentations officielles.

Non, je vous y exposerai plutôt les bonnes pratiques que je préconise, tant au niveau d’une application que d’une organisation. Je répondrai également aux questions les plus courantes : quand utiliser tel ou tel niveau de log ? que mettre dans les messages de logs ?
Nom de mon blog oblige, j’utiliserai des exemples venant du monde Java. Mais vous pourrez aisément transposer ces bonnes pratiques à d’autres technologies. Et bien entendu, elles sont à adapter en fonction de votre contexte et de vos besoins.

14 prises de notes à Devoxx France 2017

Tue, 25 Apr 2017 19:03:47 +0000

Les vidéos des présentations données lors de l’édition 2017 de la conférence Devoxx France sont d’ores et déjà disponibles sur la chaîne Devoxx FR de Youtube. Si vous n’avez pas le temps de toutes les visionner, si vous souhaitez vous faire un avis avant de les regarder ou si vous souhaitez garder une trace écrite de ce que vous y avez appris, je mets librement à disposition quelques-unes de mes notes. Il y’en a pour tous les goûts : du Java pur et dur, du framework avec Spring, du front avec Vue.js, des conteneurs avec Docker Swarm mode, des nouvelles approches de développement avec la programmation réactive, des patterns d’architecture avec les microservices, CQRS et l’Event-Sourcing, du legacy tendance avec les logs, et du Big Data avec Elasticsearch.

16 prises de notes à Devoxx France 2016

Thu, 12 May 2016 17:14:54 +0000

Pour vous aider à choisir quelle conférence visionner sur la chaîne Devoxx FR 2016 de Youtube ou pour vous remémorer certaines chose, je mets librement à votre disposition les différentes notes que j’ai pu prendre sur mon laptop.

Les sujets sont variés : des Microservices avec Spring Boot et Spring Cloud, du Big Data avec Kafka et Elasticsearch, du Front End avec ECMAScript 2015 et React, du Java 8 et 9 ou bien encore de la méthodologie avec les revues de code et de la living documentation.

Certaines notes pourront être lues de manière autonome ; je pense par exemple au quickie Comment rater ses revues de code ? et à la conférence Stack Overflow behind the scenes. Pour être exploitables en l’état, d’autres notes demanderont à ce que vous ayez assisté à la conférence ou que vous ayez pu récupérer les supports de présentation.

Tout sur le Elastic{ON} Tour Paris 2015

Fri, 13 Nov 2015 13:00:47 +0000

Sur les 12 représentations mondiales, la 3ième date de la tournée européenne de l a conférence Elastic{ON} a eu lieu le 5 novembre 2015 à Paris.

Invité par la société Adelean, j’ai pu y participé. Pour toutes celles et ceux qui n’ont pas eu cette chance, ce billet me permet de vous faire partager cette journée.

18 prises de notes à Devoxx France 2015

Tue, 21 Apr 2015 06:03:20 +0000

En attendant que les vidéos des différentes conférences de l’édition 2015 de Devoxx France soient mises en ligne sur Parleys et en complément de certains supports déjà mis en ligne par certains Speakers, je mets librement à votre disposition les différentes notes que j’ai pu prendre sur mon laptop.

Les sujets sont variés : du Machine Learning avec Watson, Spark et MMLib, du Reactive Programming avec RxJava et Vert.x, du Java 9, du Spring 4.1 ou bien encore du Docker.

Certaines notes pourront être lues de manière autonome ; je pense par exemple au quickie Stratégie de mise en place de revues de code et à la conférence Livrer chaque jour ce qui est prêt !. Pour être exploitables en l’état, d’autres notes demanderont à ce que vous ayez assisté à la conférence ou que vous ayez pu récupérer les supports de présentation.

NoSQL Matters Paris 2015

Tue, 31 Mar 2015 16:32:57 +0000

Ayant gagné une place par le groupe utilisateurs Elasticsearch (que je remercie une nouvelle fois), j’ai eu l’opportunité d’assister pour la première fois à une conférence dédiée au NoSQL. Parmi la centaine de participants, je devais sans nul doute être le plus néophyte. Certes, je connais relativement bien Elasticsearch pour l’avoir mis en œuvre, mais l’écosystème d’Hadoop et des bases de données NoSQL restait pour moi encore très vague. Ce fut donc l’occasion rêvée d’approfondir mes connaissances sur le sujet et de m’aérer l’esprit. Cerise sur le gâteau, cette conférence m’aura permis d’apprécier la qualité de speaker de deux anciens collègues, Bruno Guedes et Lucian Precup.

Etude de cas Spring Integration

Wed, 11 Mar 2015 06:30:58 +0000

Vous avez déjà entendu parler d’ Apache Camel ? Les Design Pattern n’ont plus de secrets pour vous ? L’Event Driven Architecture vous attire ? Les Enterprise Integration Pattern vous interpellent ? Vos applications reposent sur TCP, JMS, FTP, SFTP, les fichiers, les mails, XML, les web services SOAP, REST, RSS, JPA, JDBC ou même Twitter ?

N’attendez plus : venez découvrir l’utilisation des patterns comme le Channel Adapter, le Router ou l’ Aggregator au travers d’un workshop sur Spring Integration.

Plugin exit pour LogStash

Sun, 09 Nov 2014 11:15:07 +0000

Ce billet a pour objectif de vous présenter un cas d’usage du plugin exit pour LogStash. Une utilisation répandue de LogStash consiste à alimenter Elasticsearch à partir de fichiers de logs. Extensible via un mécanisme de plugins, LogStash sait gérer plusieurs types de source et plusieurs types de destinations. Une utilisation alternative de LogStash consiste à l’utiliser comme batch d’indexation. Le fichier à indexer a une fin. Et l’utilisateur souhaite que LogStash s’arrête une fois les données importées.

Développer et industrialiser une web app avec AngularJS

Sun, 09 Feb 2014 19:13:56 +0000

Au travers du billet Elastifiez la base MusicBrainz sur OpenShift, je vous ai expliqué comment indexer dans Elasticsearch et avec Spring Batch l’encyclopédie musicale MusicBrainz. L’index avait ensuite été déployé sur le Cloud OpenShift de RedHat.
Une application HTML 5 était mise à disposition pour consulter les albums de musique ainsi indexés. Pour m’y aider, Lucian Precup m’avait autorisé à adapter l’application qu’il avait mise au point pour l’atelier Construisons un moteur de recherche de la conférence Scrum Day 2013.
Afin d’approfondir mes connaissances de l’ écosystème JavaScript, je me suis amusé à recoder cette application front-end en partant de zéro. Ce fut l’occasion d’adopter les meilleures pratiques en vigueur : framework JavaScript MV*, outils de builds, tests, qualité du code, packaging …
Au travers de ce article, je vous présenterai comment :

Mettre en place un projet Anguler à l’aise d’ Angular Seed, Node.js et Bower
Développer en full AngularJS et Angular UI Bootstrap
Utiliser le framework elasticsearch-js
Internationaliser une application Angular
Tester unitairement et fonctionnellement une application JS avec Jasmine et Karma
Analyser du code source JavaScript avec jshint
Packager avec Grunt le livrable à déployer
Utiliser l’ usine de développement JavaScript disponible sur le Cloud : Travis CI, Coversall.io et David

Le code source de l’application est bien entendu disponible sur GitHub et testable en ligne.

Retour d’expérience sur les problématiques Elasticsearch

Mon, 16 Dec 2013 14:23:37 +0000

« Près de 2 ans passés chez un client en tant que référent technique d’un middle de recherche basé sur le moteur de recherche Elasticsearch, il me paraît aujourd’hui opportun de vous faire part des différentes problématiques rencontrées au cours des développements et de son exploitation. »

En 2 versions majeures et une montée de version d’Elasticsearch, les problématiques abordées ont été nombreuses : occupation mémoire, ré-indexation sans interruption de service, Split Brain, IDF et partitionnement. Prêts pour ce retour d’expérience ? »

Elastifiez la base MusicBrainz sur OpenShift

Fri, 15 Nov 2013 19:35:01 +0000

Pour les besoins d’un workshop sur Elasticsearch, je me suis amusé à indexer une encyclopédie musicale et à mettre en ligne une petite application HTML 5 permettant de réaliser des recherches.

Comme source de données musicale, j’ai opté pour MusicBrainz qui est une plateforme ouverte collectant des méta-données sur les artistes, leurs albums et leurs chansons puis les mettant à disposition du publique.

Pour indexer les données depuis une base PostgreSQL, j’ai privilégié Spring Batch au détriment d’une river. Pour l’IHM, j’ai adapté un prototype basé sur AngularJS, jQuery et Bootstrap qu’avait réalisé Lucian Precup pour la Scrum Day 2013. La mise en ligne de l’index Elasticsearch m’aura permis de tester la plateforme Cloud OpenShift de Redhat.

Cet article a pour objectif de décrire les différentes étapes qui m’ont été nécessaires pour réaliser ma démo et d’expliquer ce que j’ai librement rendu accessible sur GitHub et Internet.

Architecture d’un middle d’indexation

Tue, 26 Feb 2013 10:35:42 +0000

Dans un précédent billet, je vous ai présenté les solutions mises en œuvre sur un projet pour paralléliser un batch d’indexation alimentant un moteur de recherche d’entreprise. Utilisée pour initialiser l’index de recherche puis le resynchroniser quotidiennement, la technique d’intégration par batch ne permet cependant pas d’indexer les données au fil de l’eau. Ce billet aborde précisément cet aspect. En effet, le fil de l’eau ou le quasi temps réel fut dès le départ une exigence forte du métier. Recherches instantanées et auto-complétion révolutionnent le traditionnel formulaire de recherche mettant plusieurs secondes à renvoyer les résultats. Mais au prix de faire des recherches sur des données pouvant dater de J-1 ? Ce n’était pas acceptable ! Un middle d’indexation fut la réponse apportée.

Parallélisation de traitements batchs

Sat, 01 Dec 2012 17:54:55 +0000

Contexte

Récemment, j’ai participé au développement d’un batch capable d’indexer dans le moteur de recherche Elasticsearch des données provenant d’une base de données tierce. Développé en Java, ce batch s’appuie sur Spring Batch, le plus célèbre framework de traitements par lot de l’écosystème Java
Plus précisément, ce batch est décomposé en 2 jobs Spring Batch, très proches l’un de l’autre :

le premier est capable d’initialiser à partir de zéro le moteur de recherche
et le second traite uniquement les mouvements quotidiens de données.

Problématique

Au cours du traitement batch, l’exécution de la requête par Oracle pour préparer son curseur a été identifiée comme l’opération la plus couteuse, loin devant la lecture des enregistrements en streaming à travers le réseau, leur traitement chargé de construire les documents Lucene à indexer ou leur écriture en mode bulk dans ElasticSearch. A titre d’exemple, sur des volumétries de production, la préparation côté serveur Oracle d’une requête SQL ramenant 10 millions d’enregistrement peut mettre jusqu’à 1h30.

Avec pour objectif que le batch passe sous le seuil de 2h à moindre coût, 2 axes d’optimisations ont été étudiés : diminuer le temps d’exécution par Oracle et diminuer le temps de traitement.

Solutions étudiées

Les optimisations d’un DBA consistant à utiliser des tables temporaires et des procédures stockées n’ont pas été concluantes : trop peu de gains (10 à 20%) pour une réécriture partielle de notre batch, et avec le risque d’engendrer des régressions.

Après mesures et calculs, l’utilisation de la pagination sur des plages de 100, de 1 000 ou même de 10 000 enregistrements a également été écartée. Dans notre contexte, cela aurait dégradé les performances. Le choix de rester sur l’utilisation d’un curseur JDBC a été maintenu.
A cette occasion, nous avons remarqué que les temps de mise en place d’un curseur Oracle pour préparer 1 millions ou 10 millions d’enregistrements étaient du même ordre de grandeur.

Utilisant déjà l’une des techniques proposées par Spring Batch pour paralléliser notre traitement batch, pourquoi ne pas refaire appel à ses loyaux services ?