Introduction

Sous ce titre pompeux et aguicheur, je vais vous expliquer avec une série de posts comment je monitore mon infrastructure IT domestique (comprenez 3 Raspberry Pi).

Ok, ça fait un peu tromperie sur la marchandise, mais le principe est le même sur une infra plus classique (sauf pour la partie alerting, mais on y reviendra).

Dans nos modèles Meurise, MCD, SGBDR, la relation entre tables est naturelle.  Avec du NoSQL,  ça l’est moins. Mongo nous propose des pistes de modélisation, mais je ne trouvais pas les solutions satisfaisantes. Je m’explique. Imaginons, une collection d’auteurs et une collection d’articles. Avec un SGBDR classique on aurait : D’après Mongo, il y a 2 solutions :

1. On inclue le document auteur (tout ou partie) dans le document article
   • Avantage : quand on veut la liste des articles, on a les infos de l’auteur avec
   • Inconvénient : quand l’auteur change une de ces infos présente dans le document article, il faut faire 2 mise à jour des données
2. On a une référence de l’auteur (son id) dans le document article.
   • Avantage : les mises à jours sont simplifiées
   • Inconvénient : on est forcé de récupérer la liste des articles, puis pour chacun d’eux, récupérer l’id de l’auteur, rechercher tous les auteurs dont l’id se trouve dans cette liste et enfin raccrocher l’article à son auteur. 2 requêtes et des manipulations de listes côté serveur.

Mais alors est-ce possible de tout récupérer en un seul appel avec une référence de l’auteur dans l’article? Après un peu de recherche oui.

Pour les besoins d’une conférence sur Apache Camel, je trouvais sympa d’afficher les live-tweets sous forme de notification Ubuntu pendant le déroulement des slides. (J’avais trouvé l’idée du Tweet-wall du DevoXX sympa) En creusant un peu, je suis tombé sur la librairie GTK.jar fournie par java-gnome.

Le composant camel-kafka dédié au framework Camel et permettant des interactions avec le bus Kafka est disponible : camel-kafka La documentation se trouve là : Usage

Dans la même lignée que le mariage Thrift-Camel, ça me trottait depuis longtemps dans la tête de marier Kafka et Camel. Kafka est un bus événementiel très performant de type publish/subscribe. Il gère de la persistance, se coordonne avec Zookeeper fonctionne en cluster. J’avais dans l’idée de créer un composant Camel pour produire et consommer des messages et c’est chose faite.