Voici un compte rendu du Meetup Nantes Monitoring de mai 2017

Présente ta stack

Léo / Matlo

Léo de Matlo nous a présenté son utilisation de prometheus https://prometheus.io/ . Matlo a commencé à migrer vers une solution SASS (monitoring as a service) chez https://bleemeo.com/ (entreprise Toulousaine). La stack de bleemeo est décrite sur stackshare: https://stackshare.io/bleemeo/bleemeo. L'agent de bleemeo est publié en logiciel libre https://github.com/bleemeo/bleemeo-agent et repose sur telegraf https://github.com/influxdata/telegraf . Bleemeo semble utiliser MQTT-SSL pour remonter les métriques permettant ainsi un usage raisonnable des connexions réseau (cf diagramme https://bleemeo.com/features/).

https://bleemeo.com/images/bleemeo_agent.png

Emeric / OasisWork

Emeric de OasisWork nous a présenté leur utilisation de sensu https://sensuapp.org/ qui permet d'avoir une architecture en mode "push". La configuration se fait par "rôles" coté serveur, simplifiant la configuration des agents. Des plugins sont utilisables pour les checks https://sensuapp.org/plugins et Oasiswork a contribué à ces plugins (https://github.com/oasiswork/sensu-community-plugins/) et en a écrit en python (habituellement c'est en ruby principalement). Sensu a la particularité d'utiliser dans son architecture RabbitMQ pour le transport https://sensuapp.org/docs/latest/overview/architecture.html. Pour la visualisation l'interface web libre de sensu est utilisée : uchiwa.

https://uchiwa.io/img/browser.png

Arthur / Logilab

J'ai fait un bref exposé de nos briques de supervision/monitoring à Logilab. Du munin, du shinken, du statsd, graphite, graphite events, grafana, et en particulier la génération de ces configuration (coté serveur et client) par Saltstack. Nous utilisons aussi salt pour remonter des métriques en utilisant son bus de communication zmq à l'échelle de notre infrastructure, permettant par conséquent de re-développer des équivalents de smokeping et weathermap avec salt, carbon, graphite et grafana. Pour plus de détails sur ce type d'architecture voir les épisodes précédents (, ici, et aussi, et là).

https://www.logilab.org/file/10125980/raw/architecture.png

Quels outils choisir pour son monitoring ?

Exercice difficile, nous avons listé les produits connus par les participants puis un certain nombres de critères de choix, et puis nous avons rempli (partiellement) un tableau en discutant de chaque point.

Produits

  • nagios
  • shinken
  • icinga
  • sensu
  • prometheus
  • ELK
  • packet beats
  • file beats
  • zabbix
  • centreon
  • check-mk
  • ganglia
  • statsd
  • graphite
  • influxdb
  • telegraf
  • cadvisor
  • graylog
  • rsyslog
  • splunk
  • thruk
  • collectd
  • metrics(java)
  • logentries
  • datadog
  • bleemeo
  • prtg
  • munin
  • smokeping
  • fluentd
  • dynatrace
  • OMD

(liste non-exhaustive, forcément... )

Critères

  • language
  • prix
  • age
  • maintenu
  • communauté
  • scalable
  • facilité de mise en place (pkgs, devops, etc.)
  • champs d'application
  • push / pull architecture
  • configuration - format
  • configuration - serveur/agent
  • open core
  • securité
  • IOT ready
  • modularité / plugins
  • interface utilisateur (UX, interface web, etc.)
  • alertes
  • developpement de sondes

Début de tableau

Bien evidemment, nous n'avons pas rempli la totalité du tableau, mais les échanges ont été riches d'enseignements. Voici un apercu (flou) du tableau élaboré collectivement.

https://www.logilab.org/file/10125977/raw/2017-05-09%2021.16.15.jpg

Fin

En fin de meetup nous avons parlé des conférences devoxx publiés récemment https://www.youtube.com/channel/UCsVPQfo5RZErDL41LoWvk0A et des contenus sur le monitoring et l'aggrégation de logs, notamment le projet cerebro de voyage-sncf : https://github.com/voyages-sncf-technologies/cerebro

blog entry of