Quand je me suis auto formé sur Grafana, afin de créer un dashboard pour mon projet Livebox Exporter pour Prometheus, j’ai lu une phrase qui m’a bien plu: un dashboard doit d’abord raconter une histoire. L’idée première est qu’il ne faut pas tomber dans le piège de vouloir tout afficher. Un peu comme sur un CV!

Il faut donc, pour créer un dashboard utile, être un minimum inspiré pour savoir à quelles questions on souhaite répondre (si possible à peu de questions).

Livebox Exporter me sert de sonde pour suivre la qualité de ma connexion Internet. Son dashboard associé devait donc me donner des métriques sur le débit et sur l’état opérationnel ou non de la connexion, que ce soit en temps réel ou sur une plage de temps long (c’est-à-dire quelques mois). L’idée est de pouvoir à la fois détecter les incidents ponctuels et observer les évolutions, à partir d’une tendance de référence.

Je me suis récemment aperçu que le dashboard que j’ai publié pour Grafana ne racontait pas l’histoire que je pensais raconter.

J’ai eu une perte de connexion pendant environ 10 minutes un jour de télétravail. 10 minutes c’est court a posteriori mais on ne sait jamais combien de temps la coupure va durer, et c’était avant qu’il y ait un émulateur pour Azure Service Bus (mon projet du moment en dépend). J’ai logiquement regardé les métriques que j’avais dans le dashboard sur différentes plages de temps et je me suis rendu compte qu’en « dézoomant » (plage longue au lieu de plage courte), l’incident disparaissait. J’ai compris que Grafana affichait une moyenne sur ma courbe. En y réfléchissant, c’est logique car on pourrait très bien préférer connaître la moyenne (dans un sens « plus vraie » si on affichait indirectement un « coût » financier par exemple), ou bien connaître les pics à la hausse ou à la baisse. Sans plus d’indication sur quoi afficher, on a par défaut une sorte de moyenne.

En « zoomant » et en parcourant l’historique, je me suis rendu compte que ma Livebox avait une petite vie cachée faite de micro coupures, sans doute causé en partie par les mises à jour de maintenance d’Orange, en partie par de vraies interruptions de service. D’un certain point de vue, c’est rassurant car on sait bien que rien n’est parfait. Une courbe parfaitement stable est par nature imparfaite.

Je ne suis expert ni en graphiques, ni en mathématiques, ni de Prometheus. J’ai malgré tout trouvé la solution: les fonctions max over time et min over time de Prometheus, adaptés sur les métriques de type Gauge. Comme leur nom l’indique, elles calculent le maximum ou le minimum d’une métrique sur une période d’échantillonage. Par exemple pour le graphique de l’historique de statut opérationnel de la Livebox, je m’intéresse au min over time (le statut vaut 0 ou 1). Je peux ainsi visualiser les interruptions de connexion, même très courtes, sur de longues plages temporelles.

Après avoir mis à jour les graphiques du dashboard, celui-ci racontait une histoire bien plus intéressante. Ma connexion est certes de bonne qualité mais elle a régulièrement des petites coupures de quelques minutes, souvent à des plages horaire sans conséquence (j’en déduis qu’il s’agit le plus souvent de mises à jour de maintenance ou de coupures de maintenance planifiée sur le réseau).

L’image suivante permet de comparer le rendu du dashboard avant (sans) et après (avec) les fonctions min/max over time, sur les 90 derniers jours. On voit que l’histoire n’est pas du tout la même:

Les courbes les plus utiles pour repérer le nombre de coupures sont « ONT throughput history » et « Signal power ». La courbe « Livebox status history » peut avoir plusieurs changements d’état pour une même coupure (typiquement les variations d’état pendant le (re)démarrage de la Livebox).

Par curiosité, j’ai vérifié les graphiques d’autres dashboards populaires que j’utilise notamment pour monitorer mon cluster kubernetes. Et oh surprise, les courbes ne sont que des moyennes.

Je ne sais pas ce que l’utilisateur « moyen » attend de ces courbes, mais ce qui m’intéresse est de savoir si mon petit serveur tient la charge. En effet c’est un serveur conçu pour être efficace mais à l’économie: le processeur Intel Core i3-8100 3.6 GHz qui m’a couté 15€ d’occasion sur le Bon Coin, 16 Go de RAM. Certes la RAM peut être moyennée mais le CPU non, à mon sens. S’il y a des pics d’utilisation, je souhaite les voir pour m’assurer que je ne surcharge pas le système avec des applications trop consommatrices.

J’ai donc adapté les autres dashboards que j’ai importé de Grafana Community pour afficher ce qui m’intéresse. Ces deux fonctions me paraissent essentielles pour les courbes temporelles. C’est donc étonnant que ce ne soit pas proposé de façon plus ludique et accessible dans Grafana parmi les options principales affichées quand on crée un graphique.