Lors d’une session présentée à QCon San Francisco, Yao Yue invite à reconsidérer la manière dont sont affichées les données de mesure des systèmes. Le graphique linéaire, devenu la forme par défaut de la plupart des tableaux de bord de surveillance, peut convenir aux données propres et continues, mais il devient moins utile lorsque les séries temporelles se multiplient, que le bruit augmente ou que la question posée n’est pas fondamentalement liée au temps.
Yue s’appuie sur 15 années d’exploitation de systèmes à grande échelle, dont sept années passées à travailler en astreinte pour un service de niveau 1, ainsi que sur son expérience précédente chez Twitter, où elle a dirigé l’équipe de mise en cache avant de créer l’équipe chargée des performances. Après novembre 2022, elle a participé à la création d’IOP Systems, une entreprise qui améliore l’efficacité et la fiabilité des logiciels grâce à l’ingénierie intelligente des performances.
Le problème ne vient pas du trait lui-même
Yue explique qu’un graphique linéaire n’affiche pas seulement les points de mesure : il trace également des lignes entre chaque paire de points successifs. Cela revient à ajouter des éléments visuels qui n’existent pas réellement dans les données, ce qu’elle décrit comme de l’extrapolation, c’est-à-dire une interpolation entre les mesures. Cela peut être utile lorsque les données sont régulières, mais peut suggérer l’existence d’une trajectoire entre deux mesures alors que nous ne disposons d’aucune information directe à son sujet, notamment dans le cas de métriques pour lesquelles nous ignorons ce qui s’est produit entre ces deux mesures.
Le problème s’accentue avec les systèmes qui comprennent un grand nombre d’instances ou de séries temporelles. La multitude de lignes et de couleurs peut donner au tableau de bord une apparence riche, mais elle ne rend pas plus claires les réponses à des questions telles que « Le taux de production a-t-il changé ? » ou « Le nouveau déploiement a-t-il entraîné une dégradation notable ? ». Dans de nombreux cas, seul un ingénieur expérimenté, passant beaucoup de temps à examiner les détails, peut interpréter le graphique. Yue considère que ce mode de fonctionnement ne convient pas à une ingénierie fiable.
Choisir la forme en fonction de la nature de la mesure
L’intervenante propose de commencer par trois considérations : la forme des données, le type de mesure et ce que l’équipe souhaite en apprendre. Lorsque les données sont denses, il est possible d’utiliser des moyennes calculées sur des fenêtres temporelles ou de calculer les valeurs minimale, maximale et moyenne afin de réduire le bruit et de mettre en évidence les tendances. Toutefois, cette transformation doit répondre à la question posée et ne pas être simplement un moyen d’embellir le graphique.
Yue avertit que le résumé des données peut masquer des différences importantes. Elle cite l’idée du « Datasaurus », selon laquelle des ensembles de données peuvent partager la même moyenne et le même écart type tout en présentant des formes radicalement différentes lorsque les valeurs brutes sont représentées. Ainsi, afficher les points sans lignes peut être plus fidèle dans certains cas, car cela montre les mesures réelles sans ajouter une trajectoire visuelle incertaine.
Selon la présentation, la plupart des données de mesure se répartissent en trois grandes catégories : les compteurs, les jauges et les histogrammes. Les compteurs qui augmentent avec le temps peuvent se prêter aux lignes, mais ce qui est généralement affiché dans les applications de surveillance n’est pas le compteur brut : c’est la différence entre deux valeurs successives, comme le taux de requêtes ou d’erreurs. Yue estime que représenter cette différence sous forme de segments ou de barres peut montrer plus précisément la variation cumulée et la dispersion.
Quant aux jauges, elles ne garantissent rien sur la période située entre deux relevés. La valeur peut augmenter ou diminuer entre les deux mesures sans que cela apparaisse dans les données. C’est pourquoi l’intervenante préfère afficher les points tels quels, avec le moins d’extrapolation possible. Pour le temps de réponse, elle souligne qu’une seule valeur ne suffit pas, car il s’agit d’une distribution et non d’un nombre isolé. Les histogrammes constituent un meilleur moyen de préserver les informations de la queue, comme P99 et P99.9, plutôt que de les réduire à une seule ligne.
Qu’est-ce qui change concrètement ?
L’idée principale de la présentation ne consiste pas à remplacer tous les graphiques linéaires, mais à relier la visualisation à la question opérationnelle. Si la question porte sur l’effet de la charge sur l’accord de niveau de service, les données peuvent être regroupées par plages de charge, par exemple des plages de 500 ou de 5000 requêtes par seconde, puis associées aux distributions des temps de réponse. Le graphique établit alors une relation directe entre la charge et le temps de réponse, au lieu de parcourir différentes journées à la recherche du moment où la charge a atteint son maximum.
De même, lors de la comparaison de deux versions d’un logiciel, les mesures peuvent être regroupées par version, puis les distributions ou les quantiles comparés sans faire du temps l’axe principal de l’analyse. Pour choisir un type de matériel, l’idée consiste à associer les données de performance à d’autres informations, comme le type d’instance et le prix, afin d’obtenir un tableau comparant les éléments réellement pertinents pour la décision de dimensionnement.
Lecture de certi.news
Cette vision révèle une limite de l’architecture des outils de surveillance autant qu’un problème de conception visuelle. Les systèmes de stockage des mesures sont généralement construits autour du nom de la métrique et de ses attributs d’une part, et des valeurs et horodatages d’autre part. Cela rend les requêtes portant sur la valeur au fil du temps relativement simples, mais complique la mise en relation des valeurs d’une métrique avec celles d’une autre, par exemple pour relier le temps de réponse à la charge ou comparer les performances par version logicielle.
En pratique, cela signifie que l’amélioration d’un tableau de bord de surveillance ne commence pas toujours par le choix d’une couleur ou d’un nouveau graphique, mais par la définition de la décision qu’il doit aider à prendre. Les équipes peuvent avoir besoin de regrouper à nouveau les données ou d’intégrer des sources externes à la base de séries temporelles. Parallèlement, la session ne fournit pas de recette unique valable pour tous : elle souligne que le type et la forme de la mesure ainsi que la question posée déterminent la représentation la plus appropriée, et que la source n’établit pas que tous les outils de surveillance actuels proposent automatiquement ces transformations. La possibilité d’expérimenter, l’accès aux données brutes et la compréhension des limites de chaque résumé restent donc des questions pratiques ouvertes pour les équipes chargées de la fiabilité et de l’ingénierie des performances.