Cela fait un moment que je n’ai rien écrit… Cependant, un sujet me taraude depuis un moment… et il s’agit de la gestion des logs dans les applications.
J’ai déjà pesté dans des articles précédents sur le fait qu’une application devait toujours être monitorée et supervisée mais, en plus de cela, le comportement d’une application doit également être traçable.
Le sujet n’est pas ce qu’on peut dire le plus sexy du monde mais j’ai souvent constaté que ce dernier était souvent assez mal maitrisé.
Avec l’arrivé de Apache Spark, Hadoop est souvent vu comme désuet et legacy. Il est vrai que le monde BigData est en perpétuelle évolution et qu’un produit peut être déprécié en quelques mois.
Cependant, restreindre le terme Hadoop aux seuls technologies MapReduce, HDFS et YARN est, pour moi, une erreur.
Déjà parce que ces technologies peuvent être décorrélées et ensuite car, souvent, la très grande majorité des nouvelles technologies issues du monde BigData s’appuient sur les couches existantes et s’intègrent avec ces dernières.
Il y a déjà un long moment, j’avais posté une série d’article expliquant comment il était possible de faire des web service de type REST de manière simple via RestEasy-Netty ou via Undertow.
Dans la continuité de cette course au plus léger, je me suis dit que cela pouvait être intéressant de faire une petite étude un peu plus exhaustive des solutions légères qui existaient.
L’objectif étant extraire une sorte de bench un peu naïf et un peu out of the box.
Il y a quelques temps, j’avais fait une série d’articles sur resteasy-netty et resteasy-netty4.
Cette article repart du même besoin, à savoir disposer d’une stack légère pour réaliser un service REST, mais en utilisant Undertow plutôt que Resteasy-Netty.
Au niveau des besoins, ils seront identiques ie. :
utiliser JAX-RS, intégrer Swagger, intégrer Jolokia, générer un livrable autoporteur. RestEasy-Netty, même s’il existe de nombreux points d’entrée, demande quelques phases de hack (gestion du crossover domain par exemple) et dispose d’un mécanisme un peu limité concernant la partie sécurité.
Pour ceux qui auraient manqué l’information, le BreizhCamp s’est déroulé en mai dernier et j’y avais la chance d’y présenter un talk sur un retour d’expérience concernant le passage à l’échelle d’un SI afin de lui permettre de supporter 4 millions d’utilisateurs.
Le synopsis était le suivant :
De 20 000 à 4 millions d’utilisateurs
Pour ce faire, il a été nécessaire de revoir certaines parties du SI afin de pouvoir stocker en masse les données des utilisateurs mais également afin d’être capable de les traiter.
Encore un an de plus pour le breizhCamp qui vient de fêter sa quatrième année.
Pour ceux qui ne seraient pas encore au courant de ce qu’est le breizhCamp, il s’agit d’une conférence technique qui se veut être un mix de technologies (même s’il faut bien reconnaitre que Java y est majoritairement représentée…) qui a eu lieu du 21 au 23 mai 2014 à Rennes dans les locaux de l’ISTIC.
Spark est un framework qui a de plus en plus le vent en poupe et le fait qu’il ait été promu en top-level project par la fondation Apache qu’il a rejoint récemment (en juin 2013) montre bien de l’intérêt qu’il succite (cela est d’aileurs confirmé par son intégration avec des solutions comme celles de DataStax (cf. ici) ou mapR (cf. ici).
Un des points central de Spark est son utilisation des RDDs (Resilient Distributed Datasets).
De nombreuses applications ou systèmes d’informations nécessitent le chargement de données issues de fichiers.
Bien souvent, cet import est exécuté par batch, mais il peut aussi être intéressant de faire cet import au fil de l’eau.
En outre, bien souvent, les fichiers à importer sont, soient nombreux, soient volumineux. Du coup, écrire un code simple et fiable peut devenir plus ardu que ce qu’il n’y parait. Si, de plus, on veut ajouter des logs parlant (c’est à dire avec, au minimum, le temps de traitement d’un fichier et son nom), cela a tendance a rajouter du bruit au code.
Cet article fera un rapide tour d’horizon sur les différentes stratégies qui peuvent être utilisées pour Logstash.
Pour ce faire, je m’appuierai sur le très bon livre officiel que je me suis procuré (moyennant environ 10€) et qui fournit une très bonne vision sur ce qui est possible de faire ainsi que sur les différents concepts mais également sur les différentes stratégies de déploiement.
Même si je résumerai succinctement quelques-uns des concepts afin que cet article soit un minimum compréhensible, cet article traitera surtout sur la façon dont il est possible de déployer les agents Logstash.
Comme certain ont pu le constater, le look & feel du blog a évolué et j’espère qu’il vous plait.
Normalement, en plus d’un meilleur confort pour moi lorsque j’écris, une amélioration devrait être visible sur le temps de chargement des pages en raison d’un allègement de ces dernières.
Cependant, en raison d’une limitation de feedburner sur la taille du fichier atom.xml, j’ai été obligé de ne faire pointer que la catégorie Java (je n’ai pas trouver comment il était possible de générer ce fichier avec seulement une partie de l’article ou juste le titre…).
