Meetup Paris Monitoring #6 : interview de Mathias Herberts de Cityzen Data pour « Not Your Father’s Monitoring »

Posted by on 25 Mai 2016 in Conférences & Salons, Interviews, Planet, Supervision | Commentaires fermés sur Meetup Paris Monitoring #6 : interview de Mathias Herberts de Cityzen Data pour « Not Your Father’s Monitoring »

Le 6e Meetup Paris Monitoring a eu lieu le mercredi 18 mai et avait pour thème « la collecte, le stockage et la manipulation de métriques/séries temporelles ». Cet événement était sponsorisé par Logmatic.io et Ikoula.

Durant ce meetup, Mathias Herberts (@herberts), Co-fondateur et CTO (Chief Technology Officer) de Cityzen Data (@CityzenData sur Twitter) a fait une présentation intitulée « Not Your Father’s Monitoring ». Dans cette présentation, il a d’abord rappelé l’historique de la collecte de données temporelles puis a mis en perspective les manques de ces outils et les nouveaux enjeux auxquels les administrateurs systèmes et réseaux doivent faire face. L’un des outils répondants à ces nouveaux enjeux est Warp 10, plate-forme open-source éditée par Cityzen Data permettant la collecte et l’analyse de données temporelles géospatiales. La conférence était très intéressante car Mathias remettait en perspective les outils qu’il présentait notamment  :

  • les raisons de leur création, les buts poursuivis par ces outils à leur naissance
  • l’époque à laquelle ils ont été créés et les contraintes/les enjeux liés à cette époque.
Mathias Herbert

Mathias Herbert

Photo prise par Barbora Ballkova de Somone.

Vous pouvez télécharger directement les fichiers MP3 ou OGG pour une écoute offline en cliquant sur les icônes correspondantes.

mp3 mp3

 

Read More

Meetup Paris Monitoring #6 : interview du sponsor Ikoula

Posted by on 24 Mai 2016 in Conférences & Salons, Interviews, Planet, Supervision | Commentaires fermés sur Meetup Paris Monitoring #6 : interview du sponsor Ikoula

Le 6e Meetup Paris Monitoring a eu lieu le mercredi 18 mai  et avait pour thème « la collecte, le stockage et la manipulation de métriques/séries temporelles ». Cet événement était sponsorisé par Logmatic.io et Ikoula déjà bien connu des participants car c’est la deuxième fois qu’ils sponsorisaient un meetup Paris Monitoring, le premier étant un crossover Paris Monitoring / DevOps.

À cette occasion, nous en avons profité pour interviewer Jules-Henri Gavetti, le fondateur d’Ikoula, hébergeur français bien connu afin qu’il nous présente sa société et ses services proposés mais aussi les raisons qui font qu’Ikoula sponsorise le Meetup Paris Monitoring. Jules-Henri nous parle aussi des outils de supervision utilisés par Ikoula.

Vous pouvez télécharger directement les fichiers MP3 ou OGG pour une écoute offline en cliquant sur les icônes correspondantes.

mp3 mp3

 

Read More

Meetup Paris Zabbix #1 avec Alexei Vladishev le 23 juin 2016 chez Blablacar

Posted by on 11 Mai 2016 in Conférences & Salons, Planet, Zabbix | Commentaires fermés sur Meetup Paris Zabbix #1 avec Alexei Vladishev le 23 juin 2016 chez Blablacar

Le groupe Meetup Paris Monitoring s’étend et propose un Meetup Paris Zabbix UG (User Group) le 23 juin 2016. Fait marquant de ce meetup, la participation d’Alexei Vladishev, créateur de Zabbix, logiciel libre de supervision et de monitoring, fondateur et CEO de Zabbix LLC, la société éditrice de Zabbix. Meetup à ne pas manquer si vous êtes fan de Zabbix!

Le meetup aura lieu le jeudi 23 juin 2016, dans les locaux de la société Blablacar, sponsor de l’événement mais aussi utilisateur de Zabbix. Pour rappel, un cas d’utilisation de Zabbix avait déjà été réalisé par Blablacar lors du premier meetup Paris Monitoring en juin 2015 :

« 23k métriques & 6,5k alertes, 300 tests par seconde avec Zabbix: comment fait-on chez BlaBlaCar ? »
Par Jean Baptiste Favre / @jbfavre / http://www.jbfavre.org

À noter que vous pouvez proposer des sujets si vous souhaitez faire un retour utilisateur de Zabbix.

Pensez à vous inscrire sur le site pour participer à l’événement.

Correctif : le meetup aura bien lieu le jeudi 23 juin (et non le 26 comme mentionné précédemment).

Read More

Ne dites plus « ELK » mais « The Elastic Stack »

Posted by on 18 Avr 2016 in Analyse, ELK, Planet | Commentaires fermés sur Ne dites plus « ELK » mais « The Elastic Stack »

Il y a quelques temps déjà, nous vous avions présenté ce qu’on appelle « la pile ELK », dans un article dont le titre est « ELK : Trio de charme ElasticSearch, Logstash & Kibana ». Aujourd’hui, cette pile ELK n’existe plus! Elle a évolué pour devenir « Elastic Stack ». Analysons ce changement au travers des dernières nouveautés annoncées par les développeurs d’Elastic Stack.

Petits rappels

ELK signifie ElasticSearch, Logstash et Kibana. Il s’agit de coupler les 3 logiciels pour obtenir une solution d’analyse de log performante et complète. Les outils sont:

  • ElasticSearch : moteur de stockage et d’indexation de documents et moteur de requête/d’analyse de ceux-ci
  • Logstash : analyse, filtrage et découpage des logs pour les transformer en documents, parfaitement formatés notamment pour ElasticSearch
  • Kibana : dashboard interactif et paramétrable permettant de visualiser les données stockées dans ElasticSearch

Ces outils libres sont développés par la même structure, la société Elastic, qui encadre le développement communautaire et propose des services complémentaires (support, formation, intégration et hébergement cloud).

« ELK », jusqu’à il y a peu, n’avait un sens qu’uniquement parce que ces outils s’associent parfaitement et l’on parlait de « pile ELK » par commodité : en réalité, il n’y avait pas de « produit ELK ».

Un(?) nouveau venu

Pour répondre à de nouveaux besoins, un (un seul?) nouvel outil développé par Elastic est apparu : Beats. Beats regroupe en fait plusieurs outils différents :

  • PacketBeat : moniteur réseau
  • TopBeat : moniteur des « tops » (les processus ayant consommé le plus de mémoire vive, de CPU, …)
  • FileBeat : moniteur temps-réel des fichiers
  • WinlogBeat : moniteur temps-réel des eventlog Windows
  • LibBeat : une bibliothèque de fonctions (lib en anglais) spécialisée pour Beats

Les outils se marient parfaitement avec « la pile ELK » : les données collectées par Beats sont stockées dans ElasticSearch, peuvent être enrichies par LogStash et sont visualisées par Kibana. Ils méritent d’être liés à « la pile ELK ».

Un renommage d’abord pragmatique…

Un problème apparaît : ELK est déjà trop connoté et peu pensent à Beats lorsqu’ils parlent de « ELK » ou de « pile ELK ». Beats pourrait pâtir de ce point. Quelques questions se posent :

  • comment intégrer le B de Beats dans ELK? Doit-on parler de BELK? Il n’est pas sûr que ce point est joué mais en français, cela sonne plutôt comme quelque chose de négatif (BELK? BEULK? beurk!). Sinon, on pourrait utiliser aussi ELKB… Un peu long non?
  • comment intégrer les futurs produits? Elastic devra-t-elle trouver une lettre s’intégrant parfaitement avec ELKB ou BELK avant de trouver un nom commençant par cette lettre et représentant l’outil? Le département Marketing va avoir du boulot!

Non, il fallait trouver autre chose. Un nouveau nom pouvant intégrer tous les outils actuels et les prochains aussi. Et le nom de « The Elastic Stack » fut choisi.

… mais d’un véritable intérêt stratégique

« The Elastic Stack » sonne plutôt bien et à l’avantage de rappeler à la fois la base (ElasticSearch) mais aussi l’entreprise (Elastic) et indique qu’il s’agit d’une composition d’outils (le terme Stack). Le nom décrit parfaitement le produit tout en ouvrant la possibilité d’intégrer de futurs produits à cette stack.

Un autre intérêt stratégique est lié à ce changement de nom. Lorsqu’on compose des outils pour en faire une solution complète, un problème apparaît : la gestion des numéros de version et des incompatibilités entre les composants de cette sollution. Aujourd’hui, si l’on prend la « pile ELKB/BELK », nous avons :

  • ElasticSearch 2.3.x
  • Logstash 2.3.x
  • Kibana 4.5.x
  • Beats 1.2.x composé de :
    • Winlogbeat 1.2.x
    • Filebeat 1.2.x
    • Topbeat 1.2.x
    • Packetbeat 1.2.x
    • LibBeats 1.2.x

Comment s’assurer que tous les produits sont compatibles entre-eux? D’un point de vue technique, c’est compliqué : il faut gérer une matrice de compatibilité qui doit être fournie par l’éditeur. L’éditeur doit faire des tests en faisant varier les versions de chaque composant. Les mises à jour doivent être bien documentées pour éviter qu’un utilisateur perde des données. La matrice de compatibilité doit être claire et compréhensible, sans erreur d’interprétation possible.

D’un point de vue marketing, c’est compliqué aussi! Toute la communication doit aussi être mise en œuvre pour que les utilisateurs et les clients suivent (correctement!) la matrice de compatibilité. Lorsqu’un client ou un utilisateur mettra à jour un composant qui sera incompatible avec tous les autres, c’est l’image des développeurs et de l’entreprise qui va en pâtir par les retours sur les forums utilisateurs, les articles de blog négatifs, les présentations lors des événements communautaires (salons, forums) et les bugs ouverts. Et ces retours négatifs risquent d’être très nombreux : les outils sont jeunes et évoluent très vite et le succès est grandissant.

D’où l’idée d’Elastic de coordonner les numéros de version : désormais il y aura un produit « The Elastic Stack » dans une version donnée et intégrant tous les outils, chaque outil ayant la même version majeure. La première version de « The Elastic Stack » sera la prochaine version, la version 5.0.0 et intégrera tous les produits dans la version 5.0.0. Ce qui sera plus simple pour tout le monde : clients, utilisateurs mais aussi développeurs et ingénieurs support d’Elastic!

Refonte graphique

Pour communiquer plus efficacement sur « The Elastic stack », la charte graphique des outils a été refondue lentement. Dorénavant, il y a une unicité graphique entre les outils concernant les logos :

nouveaux logos : the elastic stack

Auparavant, les logos pouvaient être très différents :

anciens logos : ELK

Première version disponible

La première version alpha de « The Elastic Stack » est disponible en version 5.0.0 alpha 1. Bienvenu à « The Elastic Stack » et merci à « la pile ELK » pour les services rendus.

Read More

Logstash 2.3.0 : forte amélioration des performances

Posted by on 8 Avr 2016 in ELK, Planet | Commentaires fermés sur Logstash 2.3.0 : forte amélioration des performances

Logstash est un outil de collecte, de traitement et de transport de données. Logstash est disponible en version 2.3.0 depuis le 30/03/2016 et cette nouvelle version apporte, en autres, une augmentation significative des performances.

Présentation rapide de Logstash

Logstash a pour but d’ingérer des logs (fichiers journaux des systèmes et applications) ou des messages (provenant de RabbitMQ par exemple), de les analyser (filtrer les messages inutiles, les découper, extraire l’information utile, les formater) puis de les stocker, généralement dans ElasticSearch pour être indexées. La force de Logstash est de pouvoir ingérer tout type de logs :

  • des logs au format syslog : très répandus sur les systèmes GNU/Linux et Unix
  • des logs en texte brut
  • des logs Apache et Log4j
  • des logs Windows Event Logs
  • des messages au format JSON
  • des messages passant par des files de messages (RabbitMQ, ZeroMQ)

Bien entendu, vous pouvez étendre le système et faire ingérer vos propres formats. Une fois les messages ingérés, Logstash les filtre, prend des actions et/ou les formate pour les stocker dans ElasticSearch, MongoDB, Riak, …

Logstash évolue très rapidement et de nouvelles versions apportent souvent de nouveaux connecteurs, tant en entrée qu’en sortie.

Version 2.3.0 : forte amélioration des performances

La version 2.3.0 de Logstash est sortie le 30/03/2016 et cette version apporte une forte amélioration des performances. Elle se traduit par un traitement plus rapide des messages, une augmentation de la vitesse de traitement jusqu’à, dans certains cas, 79%. Cette augmentation est due à la ré-écriture en pure Java d’un composant de l’application, préalablement écrit en Ruby. L’équipe de développement de Logstash a fait des tests et a publié les résultats dont voici un résumé :

Lostash 2.3.0 : améliorations des performances diagramme

Lostash 2.3.0 : améliorations des performances diagramme

Lostash 2.3.0 améliorations des performances tableau

Lostash 2.3.0 améliorations des performances tableau

 

 

Relecture à chaud de la configuration

Cette version 2.3.0 introduit la relecture de la configuration à chaud. Cela permet de ne pas avoir à redémarrer le service lorsqu’un paramètre de la configuration est modifié : en effet, Logstash va vérifier régulièrement (toutes les 3 secondes, par défaut) si une modification a été faite sur les fichiers de configuration. Dans ce cas, il va relire les fichiers et adapter son comportement. Pratique lorsqu’on développe mais aussi lorsque la configuration est modifiée par des outils externes, en fonction de règles dynamiques : cela évite de redémarrer Logstash par un script.

Pour activer la relecture à chaud, il faut passer l’option --auto-reload lors du démarrage de Logstash.

Si jamais vous souhaitez maîtriser le moment où LogStash doit relire la configuration, il vous suffit de ne pas passer l’option  --auto-reload et d’envoyer le signal SIGHUP au processus.

Read More