Le monde de l'open source est une vaste jungle où se cotoient des projets en taille, formes et couleurs diverses et variées. Devant la diversité et la technicité, il est difficile de faire des choix technologiques éclairés. Faute d'arguments tangibles, les développeurs, comme tout consommateurs, sont sujets à des biais importants liés à leurs habitudes et leur ressenti affectif.
Les projets redoublent alors d'imagination pour vanter leurs mérites : «scalable», «lightweight», «performant», «flexible», «easy to use», «no dependency»... Ces fourre-tous, à la fois subjectifs et non quantifiés, sont des exemples de discours marketing, alors qu'un professionel doit pouvoir comparer des solutions sur des bases objectives.
Je vais vous donner quelques clés d'évaluations des solutions de monitoring que je connais, ce que nous avons choisi à Yaal et pourquoi. Je vous partage ici mon expérience, d'une part en tant que développeur de solution de monitoring, d'autre part en tant qu'utilisateur de divers outils.
Du besoin de monitoring
Le monitoring est un secteur en plein boom dans l'industrie informatique qui connait depuis plusieurs années des croissances fortes. Les études de marché lui donnent des perspectives pour le moins encourageantes : le marché devrait prendre encore 50% d'ici 2024 (source). La startup Datadog a réalisé début 2016 une levée de fond de près de 100 000 000$ (source). Une longue liste de projets de monitoring opensource ont vu s'accumuler des communautés respectables, telles que celle de Sensu (2600 «stars» sur github), et d'autres projets stables tels que Shinken, Nagios ou Zabbix...
Les raisons sous-jacentes sont liés à l'évolution des systèmes informatiques. Ils sont non seulement toujours plus nombreux, mais aussi toujours plus vastes, toujours plus complexes, leurs enjeux sont aussi économiquement critiques. Surveiller l'évolution et le bon fonctionnement des systèmes a donc intrinsèquement une valeur croissante.
Pour une entreprise technologique les enjeux du monitoring sont multiples : avoir un système monitoré, c'est se donner les chances d'être réactif en cas de panne, de cibler les optimisations, et de provisionner correctement le besoin matériel. En somme, le monitoring est à l'informatique ce que la business intelligence est au commerce : un enjeu stratégique de premier ordre.
Il existe près d'une centaine de solutions avec des approches parfois très différentes. Pour ce secteur encore plus que pour d'autres, le choix est difficile car il n'existe aucune référence incontestable. La raison est qu'il est difficile de quantifier ce qui constitue un monitoring efficace, ce qui est «le besoin» : le monitoring recouvre en fait un ensemble de besoins.
Se pose alors la question, comment mesurer l'efficacité d'une solution ? Quelles métriques choisir, et quel coût raisonnable pour les atteindre ?
Une définition claire
Tel que je définis le monitoring, le monitoring d'un système s'évalue simplement par le fait que les informations pertinentes sont accessibles.
Un fantasme communément admis serait qu'un système puisse efficacement proactivement notifier d'un dysfonctionnement. Cela peut exister pour des événements exceptionnels simple, comme par exemple avertir que le site principal ne répond plus (et encore, on s'expose à nombre de faux positifs type coupure réseau localisée momentanée, du spam pendant les maintenances etc. et bon nombre de faux négatifs également). Mais il est impossible de généraliser ce fonctionnement à l'ensemble d'un système complexe, car il est difficile ou impossible pour un système de qualifier précisément l'importance d'une 404, d'une 500, d'un crash d'application, voire même d'une machine. Cette importance est entièrement situationnelle et demande de connaître l'organisation qui utilise ce système.
Les solutions lourdes de monitoring tentent de résoudre ces problèmes par effort de configuration. L'idée est de pré-qualifier l'importance de certains systèmes ou erreurs afin de pré-filtrer les avertissements. Mais on s'aperçoit en réalité que même avec cet effort coûteux, après mise en place, les avertissements sont lus à posteriori et requalifiés par un être humain qui suit une routine - lui envoyer un mail équivalait donc à lui rendre des informations pertinentes accessibles !
Mais qu'est-ce que la pertinence et l'accessibilité d'une information ?
Patterns et anti-patterns
La pertinence
Pour qu'une information soit pertinente, elle doit être en premier lieu entièrement qualifiée : elle doit répondre à quoi (qu'est-ce qui se passe ?), quand (un timestamp), où (sur quelle machine/processus), et assez souvent également combien (une quantité ou une fréquence).
Elle doit également répondre à une question, couvrir une éventualité impactante. Pour cela, il peut être nécessaire de la condenser ou de la coupler avec d'autres informations. Par exemple, un événement de visite sur un site, en tant que seule information, est peu pertinent, mais avoir une vue globale du nombre de visites et pouvoir rapprocher ces événements avec une charge serveur peut constituer une information pertinente. C'est pourquoi il est intéressant de collecter un vaste panel d'information.
Le panel choisi gagne à être diversifié. Il est intéressant de combiner des métriques précises et concrètes, correspondant à une réalité tangible (Exemple : un temps de réponse exprimé en ms) avec des agrégations de résultats dont les seuils sont aisément interprétés (Exemple : le load average); avoir également une approche multiniveau en combinant des métriques système, universelles, à des métriques applicatives, spécifique, de haut niveau.
C'est de cette façon que l'on peut créer à la fois la vue d'ensemble nécessaire comme de pouvoir descendre au plus près de problèmes précis.
L'accessibilité
Une fois cette collecte effectuée, il est indispensable d'avoir la possibilité de filtrer et explorer les données : filtrer par date, par type (erreur/warning/debug/métrique etc.), par application et par machine, sans que ces opérations soient pénibles : puisqu'accéder à ces informations est une routine, elle doit être au maximum simplifiée.
Sur tous ces points, certains canaux ou technologies sont plus ou moins efficaces. Les technologies classiques présentes d'ailleurs souvent de grosses faiblesses. Prenons l'exemple d'un fichier de log : il est indexé par le temps, et son information est plutôt qualifiée. La pertinence des informations est variable : il s'agit d'informations isolées et souvent redondantes. Il s'agit également d'un des pires média quant à l'accès à l'information : pour y accéder, je dois d'abord savoir quel fichier ouvrir sur quelle machine, et je n'ai pas beaucoup d'options de filtre. La présentation des quantités est également crue. En bref, c'est facile à mettre en place, mais la qualité est au mieux médiocre. Le mail n'est pas beaucoup mieux : en terme pratique, il s'agit d'un log dépliable.
Le bon pattern constitue l'élaboration d'un dashboard interactif et efficacement présenté. Les informations qu'il contient sont automatiquement synthétisées et mises à jour. Il peut se compléter par un certain nombre d'options pour naviguer parmis différentes données. Il doit contenir autant des données chiffrées que des informations d'événements pouvant servir de base à un ticket de développement ou de maintenance.
Notre choix
Ce premier balayage fait, il intervient alors des considérations concernant la pérénité de la solution choisie, de manière à minimiser le risque d'avoir choisi une technologie dépréciée. Il est toujours plus confortable de bénéficier d'une solution ayant un large écosystème présent et futur. Pour cette dernière partie, j'ai tendance à penser qu'il est préférable de se tourner solutions ayant découplé la collecte, le stockage et le rendu. Ces briques logicielles faisant appel à des expertises différentes, elles bénéficient généralement à être séparées et intéragir par un standard ouvert qui permet la libre concurrence.
Dans ce cas, c'est la technologie de stockage qui définit le plus profondément la solution. Il existe deux orientations : une orientation plus orientée événement, c'est le cas en particulier de la technologie Elasticsearch (fréquemment associé à Logstash et Kibana donnant ELK) : elle est éprouvée et solide. L'autre solution est plus récente et plus orientée métrique : il s'agit de notre choix, InfluxDb. Cette base de données permet la gestion du stockage des données indexées dans le temps, à la fois métriques et logs. Lorsqu'elle est correctement structurée, la base de données permet une compression temporelle des données (retention policy et downsampling), aussi bien que la gestion des filtres par des tags qui peuvent représenter les machines, les types de logs...
Nous y avons associé Grafana qui permet de voir des dashboard, produit des graphes lisibles qu'il est possible de templater, et les deux s'interfacent avec un effort de configuration minimale. Il est par ailleurs très joli.
Notre processus de collecte est quant à lui en cours d'industrialisation, mais pourrait être réalisé soit par de simple scripts, par Collectd ou Telegraph.