Du monitoring à la matière noire

J’ai participé au Breizhcamp cette année avec une présentation sur le monitoring.

Au passage merci aux organisateurs pour cette édition 2014. Les conférences sont toujours l’occasion de discussions passionnées sur les sujets les plus chaud du moment et puis c’est cool finalement de pouvoir assister à des conférences sans rien avoir à faire. Bravo aussi à l’initiative de faire un repas ouvert à tous le jeudi soir. On a ainsi pu partager les discussions passionnées des speaker diners avec d’autres passionnés.

Le but ce cette présentation est de revoir un peu nos idées reçues sur le monitoring. Même si le sujet n’est pas forcément très hype, Lean et Devops changent notre vision des mesures et les outils BigData viennent à notre secours.

La présentation se trouve .

Sébastien Brousse a twitté sur une partie de la présentation où je fais un détour par la matière noire. Je pense que le rapport avec le monitoring est peu évident sans les explications que j’ai donné de vive voix et le slide ne vous sera pas forcément d’une grande aide.

Pour ceux qui n’étaient là en attendant la vidéo voici les explications et même quelques infos supplémentaires.

Mais pourquoi la matière noire ?

Non, je n’ai pas changé de métier, la présentation parlait bien de monitoring.

Tout d’abord il y a peu de femmes dans l’informatique et donc dans les conférences, et c’était l’occasion d’avoir deux grandes dames avec nous, Margaret Burbidge et Vera Rubin, deux astrophysiciennes.

La première a imaginé le concept de matière noire, la seconde a poursuivi les travaux et mis au point une méthode pour prouver son existence.

Nous on est n’est pas des astrophysiciens, je vais rester à un niveau assez général. Pour les détails, sur la matière noire je vous renvoie à Wikipedia.

Des galaxies prises en excès de vitesse

Cette découverte a un rapport avec le monitoring parce que tout ça découle de problèmes de mesure.

Les astronomes avait constaté depuis longtemps que les galaxies spirales tournaient trop vite par rapport à la masse qu’elles sont supposées avoir d’après les mesures.

Plusieurs hypothèses ont été avancées pour expliquer cette bizarrerie en particulier l’imprécision des mesures.

Dans les années 1970, Margaret Burbidge a refait les mesures avec toute la précision des moyens de l’époque. Et là, ça ne collait toujours pas.

Plutôt que de remettre en cause les mesures, Margaret Burbidge a remis en cause le raisonnenment. Si la vitesse ne colle pas avec la masse, c’est que la masse n’est pas celle que l’on pense.

A cette époque on évalue la masse à partir des objets que l’on peut observer au téléscope, donc ceux qu’on peut voir parce qu’ils émettent de la lumière. Par conséquent, elle en a déduit qu’il y a dans les galaxies quelque chose qui a une masse mais que l’on ne voit pas parce que ça n’émet pas de lumière. C’est le concept de matière noire.

Vera Rubin qui travaillait avec Margaret Burbidge a apporté des éléments de preuve en mettant au point une méthode de calcul de la masse basée sur l’influence gravitationnelle de la galaxie sur son environnement, ce qu’on appelle la masse dynamique. A la différence de la masse lumineuse, la masse dynamique est compatible avec la vitesse de rotation des galaxie spirales. Et la masse dynamique basée directement sur l’effet de la masse n’a pas de raison d’être fausse, ce qui justifie qu’il y a un élément non visible ayant une masse.

Bon, d’accord mais moi je mesure des requêtes HTTP

Ok, nous on ne mesure pas des galaxies, mais même si on peut parfois regarder le serveur, enfin la boîte, finalement ce qu’on mesure est tout aussi peu visualisable.

Cette histoire montre que c’est important de mesurer de la bonne manière.

Si on mesure des effets indirects, on est dépendant d’un modèle. Ce modèle c’est l’idée qu’on se fait du fonctionnement du système et il peut être faux.

Dans un certain nombre de cas, cette mesure indirecte marche, par exemple la masse lumineuse convient pour les objets très lumineux comme les étoiles. Mais de temps en temps, ça ne marche pas.

Bien sûr, on n’a pas toujours la possibilité de mesurer l’effet direct, et de temps en temps on doit se baser sur une mesure indirecte parce que c’est plus abordable. Dans ce cas il faut rester vigilant, et savoir remettre en cause le modèle qu’on se fait du système.

Notre matière noire

Qu’est ce que c’est notre matière noire à nous les informaticiens ?

Ce sont les caches, les buffers, les load balancers, les heuristiques sur les files d’attente, les optimisations de JVM, tout un tas de mécanismes internes au système qui le rendent plus performant, mais qui font aussi que certaines de nos mesures ont un comportement erratique ou n’ont plus de sens dans certaines situations.

Au final, mesurer correctement les performances d’un système ou d’une application informatiques est une activité qui réserve toujours des surprises. On ne peut pas se contenter de poser des sondes au petit bonheur la chance sans comprendre ce qu’on fait. Il faut comprendre le système et comment il fonctionne pour le mesurer correctement.

On a un peu plus de chances, en cas de doute on peut souvent se reporter à la documentation (quoique à la réflexion pas toujours) ou demander au développeur (enfin des fois … ).

Mais par contre, un cache c’est beaucoup moins beau sur les photos qu’une galaxie spirale.

Les images proviennent toutes de la galerie d’images de la Nasa.

Présentation Devops au Women Techmakers Nantes

Dans le cadre du Women Techmakers Event de ce mois de mars, le Women in Technology et le GDG de Nantes organisent une soirée spéciale.

Au programme, la présentation de Women in Technology, un retour sur l’entrepreneuriat par Anaïs Vivion, et une présentation plus technique sur DevOps que j’assurerai.

La présentation se trouve en ligne ici.

Quelques retours au feeling sur Mix-IT

J’ai assisté à Mix-IT la semaine passée.

Une conférence très conviviale, impeccablement organisée grâce à la dizaine de personnes du JUG Lyon et du CARA (le Club Agile Rhône Alpes) qui y ont mis toute leur énergie, mais aussi à l’impressionnant soutien des étudiants de l’Epitech présents à tous les étages.

Et à la présence du soleil 😉

Cette première édition présentait 25 sessions organisées en 5 tracks parallèles

  • Techy : Java et son écosystème,
  • Agility : Agilité pour débutants et passionnés,
  • Trendy : Tendances novatrices et avant-gardistes,
  • Mixy : Le meilleur de l’agilité et des technologies Java,
  • Gamy : jeux agiles et coding dojos

Avec la préparation de l’anniversaire de Duchess France je n’ai pas le temps de faire un retour très documenté, mais voici quelques retours au feeling sur les diverses sessions que j’ai suivies.

Les tests du futur

Mathilde Lemée nous a présenté Spock, un framework de test basé sur Groovy qui permet de clarifier l’écriture des tests unitaires. Grâce aux labels Java, les tests peuvent être écrits selon un formalisme given / when / then explicite. Elle a également rapidement présenté Geb un outil de test fonctionnel.

Comme Mathilde a fait plusieurs articles sur Spock, le plus simple est d’aller voir ça sur son site directement : http://www.java-freelance.fr/tag/spok

Grails from scratch to production

Pour la deuxième session, j’avais déjà vu la présentation HTML5 de Cédric Beurtheret et Alain Duval déjà jouée au Paris JUG.

J’ai donc opté pour la session Grails. Grails n’est pas tout nouveau. J’ai déjà un peu joué avec le tutoriel Grails, mais je me disais qu’il y aurait peut être quelques informations sur le « en production ». En fait, la présentation d’Aurélien Maury était surtout sur le « from scratch ».

J’ai quand même eu la réponse à une question qui m’intriguait en voyant les exemples de configuration Grails. La configuration a toujours l’air en dur et quand ça part dans un war ça ne doit pas être très pratique. En fait, la réponse était déjà écrite par l’intervenant. Elle est là : Grails Tips Externalise la-configuration.

Introduction à Clojure

Après le repas, un des sujets qui me motivait le plus, Clojure. Laurent Petit nous a présenté ce langage dynamique tournant dans la JVM,   simple, fiable, performant et ultra-expressif !

Les speakers avait quand même ajouté :

Le truc ? Facile : sortez de votre zone de confort et pensez simple, le jeu en vaut la chandelle !

Et il faut vraiment sortir de sa zone de confort, car c’est quand même très différent de ce qu’on manipule tous les jours. Pour ceux qui ont fait du LISP, il y a un air de famille, mais pour les autres ça doit être proche du Vulcain. La présentation était très claire, mais très technique car elle faisait appel à des notions sur la théorie des langages.

(defn read-file [file]
    (with-input-stream (new FileInputStream file)
        (fn [is]... corps de la methode)))

A vrai dire, c’est plus facile lorsque l’on a une motivation. J’ai depuis longtemps dans mon GTD le projet d’utiliser Incanter pour quelques scripts que j’utilise pour analyser mes résultats de test de performance pluôt que R. R et Incanter sont des outils d’analyse statistique. R est inspiré de Scheme. C’est un environnement très complet mais assez loin de Java. Incanter est un outil plus récent  implémenté en Clojure. Il tourne dans une JVM et serait plus facile à interfacer avec d’autres programmes en Java.

Clojure est un langage à base  fonctionnelle avec des données immuables et des structures de données persistantes. Un mécanisme permet de gérer des changements d’états contrôlés sur un mode transactionnel si nécessaire.

Je n’ai pas trouvé la présentation de cette session, mais si Clojure vous intéresse vous pouvez lire l’interview donné par les speakers sur le site de Duchess France http://jduchess.org/duchess-france/blog/session-clojure-a-mix-it/ et la retranscription par Olivier Croisier d’une conférence sur Clojure à Paris avec une discussion en Google Wave qui compare Clojure et Scala http://thecodersbreakfast.net/index.php?post/2010/02/08/Conf%C3%A9rence-Clojure-chez-Zenika-%3A-le-compte-rendu

Félicitations à Laurent Petit qui a assumé tout seul 2 sessions à la suite et bon rétablissement à Christophe Grand absent pour un problème de santé.

Intelligence collective avec Apache Mahout

Mahout est un outil d’apprentissage automatique et d’analyse de données. C’est le type d’outil qui est utilisé pour faire de la catégorisation de textes dans les moteurs de recherche par exemple ou pour les systèmes de recommandation des sites sociaux ou de commerce. A noter ce projet Apache est co-dirigé par une femme, Isabel Drost.

La présentation de Michaël Figuière a présenté les usages que l’ont pouvait faire de ce framework et les bases de l’utilisation de l’API. ça a l’air très simple à mettre en oeuvre. a essayer un jour.

Le mouvement devops

Bien sûr je n’y suis pas allée pour découvrir le concept. J’assiste au sessions du devops group à Paris depuis la première édition. C’était l’occasion de rencontrer Gildas Le Nadan le leader de devops Lille.

Pour ceux qui n’en auraient pas entendu parler devops est un mouvement émergeant qui vise à rapprocher les équipes de développement et les opérations (la production en français) pour mieux résoudre les problèmes de déploiement et de suivi de production.

La présentation était plutôt destinée à la cible Agile de Mix-IT. Mais les imitations de sysadmin bougon de Gildas sont franchement très réalistes. A ne rater sous aucun prétexte !

La présentation de Mix-IT se trouve ici http://devops.fr/mixit/slides.pdf

Vous trouverez des ressources sur devops en français sur le site de devops Paris http://parisdevops.fr/ et des pointeurs sur les sites en anglais sur le site de Gildas http://devops.fr

Pour les gens qui habitent Lille ou Paris, vous pouvez vous rapprocher des groupes ci-dessous

A quand un groupe devops en Rhône Alpes ?

Mix-IT Lyon c’est fini pour cette année.

On attend impatiemment l’année prochaine. Mais dans l’intervalle d’autres manifestations en province s’organisent : le BreizhCamp à Rennes le 17 juin, le JUG Summer Camp à La Rochelle le 16 septembre, et j’ai même entendu parler d’une idée de Mix-IT au Luxembourg.