Monitoring : les quatre Golden Signals et leur mise en pratique

Les quatre Golden Signals

De nombreuses métriques de performance tournent autour d’éléments tels que l’utilisation du CPU, l’allocation de la mémoire, les temps de lecture des disques ou la capacité de la bande passante interne. Pour assurer un suivi cohérent de l’expérience des utilisateurs finaux, l’équipe d’ingénieurs spécialisés dans la fiabilité des logiciels (Software Reliability Engineers, SRE) de Google a créé un standard interne basé sur quatre indicateurs connus sous le nom de « Golden Signals ». Cette notion inspire de nombreuses équipes SRE et est reprise par les éditeurs tels IBM, Sysdig, Splunk, ou encore New Relic pour bâtir certaines des fonctionnalités de leurs outils de supervision. Ces quatre signaux sont la latence, le trafic, les erreurs et la saturation.

Latence. Cette variable représente le temps qui s’écoule entre le moment où un système reçoit une requête et celui où il envoie une réponse. Il est tentant de considérer cette mesure comme une latence « moyenne » unique, ou peut-être une latence « moyenne » établie qui peut être utilisée pour guider les accords de niveau de service. Mais, avec les Signaux d’Or, nous voulons observer la latence sur une période définie, que nous pouvons visualiser avec un histogramme de distribution de fréquence.

L’histogramme ci-dessus illustre la latence de 1 000 requêtes adressées à un service dont le temps de réponse attendu est inférieur à 80 millisecondes (ms). Chaque section de l’histogramme regroupe les demandes en fonction du temps qu’elles mettent à être traitées, allant de 0 ms à 150 ms par incréments de cinq.

Ce graphique nous montre que, sur ces 1 000 requêtes, la plupart (105, pour être exact) ont mis environ 25 à 30 ms pour être complétées. Un nombre à peu près égal de requêtes prend entre 50 ms et 100 ms, mais ce chiffre chute radicalement à partir de 105, jusqu’à ce que l’on observe un deuxième petit pic autour de 130 ms.

Le service a une latence moyenne de 58 ms et une latence médiane de 45 ms, ce qui se situe confortablement dans la fourchette que nous recherchons. Pourtant, il y a toujours ce pic significatif sur le côté droit. En tant que tel, cet histogramme nous a donné une raison spécifique d’examiner ces requêtes sujettes à la latence et de remédier éventuellement au problème.

Trafic. Avec ce signal, il s’agit de mesurer la « demande imposée » au système. Les données à prendre en compte varient suivant si l’on supervise un site Web, un système audio ou un data store basé sur des paires clé-valeur, illustrent les ingénieurs de Google. Par exemple, un système peut avoir une moyenne de 100 requêtes HTTPS par seconde. Là encore, les moyennes peuvent être trompeuses ; vous pouvez examiner les tendances de la moyenne pour détecter les problèmes, ou les moyennes dans le temps. Il est possible que le trafic augmente largement à certains moments de la journée, par exemple lorsque les gens vérifient les cours de la bourse à la fermeture du marché. Il se peut que les retards sur le côté droit du diagramme de latence évoqué ci-dessus se produisent tous à ce moment précis.

Erreurs. Ici, l’on s’intéresse au taux d’erreurs des requêtes. Exemple, il n’est pas rare de recevoir un code d’erreur en provenance d’une API. S’il est facile de l’ignorer, la multiplication des occurrences n’indique jamais rien de bon. Le suivi du nombre total d’erreurs qui se produisent et du pourcentage de requêtes qui échouent permet à une équipe de comparer le service à d’autres. Les SRE de Google étendent ce concept aux erreurs fonctionnelles de données incorrectes et aux réponses lentes, même si l’objet à surveiller n’est pas à l’arrêt. Ils distinguent alors des échecs explicites (une erreur HTTP 500) et implicites (un message « 200 OK » associé au mauvais contenu).

Saturation. Les réseaux, les disques et la mémoire ont un point de saturation à partir duquel la demande dépasse les limites de performance d’un service. « Notez que de nombreux systèmes voient leurs performances se dégrader avant d’atteindre une utilisation de 100 %. Il est donc essentiel de placer des seuils », rappellent les SRE de Google. Vous pouvez utiliser les tests de charge pour identifier ce point de saturation, ainsi que la contrainte, c’est-à-dire la requête qui a échoué en premier. Malheureusement, il est facile d’ignorer la saturation lorsque des équilibreurs de charge et d’autres mécanismes de mise à l’échelle automatique sont en place. Cependant, des systèmes mal configurés, une mise à l’échelle incohérente et d’autres facteurs peuvent toujours empêcher les équilibreurs de charge de faire leur travail, surtout quand ce répartiteur est lui-même capricieux. La surveillance de la saturation peut aider les équipes à identifier les problèmes avant qu’ils ne deviennent graves, ainsi qu’à reconfigurer leur stratégie pour éviter qu’ils ne se reproduisent.

Les Golden signals côtoient les méthodes USE et RED

Ceux qui étudient diverses techniques de surveillance sont susceptibles de rencontrer un autre ensemble de mesures de performance des applications : les métriques de la méthode USE. Cette méthode a été imaginée par Brendan Gregg, alors Lead Performance Engineer pour Joyent (avant de prendre un poste similaire chez Netflix à partir de 2014) et popularisée à partir de 2013. Elles sont similaires aux Golden Signals, mais la perspective qu’elles fournissent s’aligne sur un objectif différent.

L’acronyme USE est constitué des mots utilisation, saturation et erreurs. L’utilisation indique le temps pendant lequel un service d’une application traite les charges de travail, tandis que la saturation est la quantité de workloads non exécutés qui réside dans les systèmes internes de l’application. La variable de « saturation » trouvée dans les Golden Signals correspond à la variable d’utilisation de USE. Cependant, l’approche Golden Signals ne permet pas de distinguer les erreurs des clients des erreurs internes. Les mesures USE le font.

« La méthode RED consiste à se soucier de vos utilisateurs et de leur bonheur, la méthode USE consiste à se soucier de vos machines et de leur bon fonctionnement. »

Le fait que ces distinctions valent la peine d’être prises en compte ou non dépend de votre système, et plus important encore, de la façon dont il « plante ». Si une équipe veut analyser un back-end pour détecter les goulets d’étranglement, mais sans inclure le backlog qui réside à l’extérieur, la méthode USE peut convenir.

En revanche, elle serait plus indiquée pour la supervision matérielle que logicielle, selon Tom Wilkie, VP Products chez Grafana Labs. Pour y remédier, lui a inventé en 2015 la méthode RED (pour Ratio – soit le nombre de requêtes par seconde –, Erreurs – le taux d’échecs de ces requêtes –, et Durée – le temps d’exécution de ces requêtes). « La méthode RED consiste à se soucier de vos utilisateurs et de leur bonheur, la méthode USE consiste à se soucier de vos machines et de leur bon fonctionnement », résume-t-il. Selon Tom Wilkie, les Golden Signals complètent la méthode RED avec un indicateur de saturation. De son côté, il recommande de combiner les méthodes RED et USE.

Les Signaux d’Or et les microservices

Dans une courte vidéo, Brenda Christopher, Product Manager Watson AIOps chez IBM affirme que les Golden Signals permettent de s’abstraire de métriques spécifiques à une technologie pour superviser des signaux communs à tous les microservices. Si ces données caractéristiques demeurent essentielles dans certains cas, il s’agit de combiner les informations obtenues par ces Signaux d’Or pour trouver la cause profonde dans une architecture par nature éparse et complexe.

Un ensemble de microservices qui prend en charge une application d’e-commerce peut reposer sur une passerelle API comme interface publique unique pour les requêtes, et un patron composite (composition pattern), une arborescence qui classe les requêtes en groupes. Dans ce cas, les mesures les plus précieuses seraient la rapidité avec laquelle les clients interrogés reçoivent des résultats (latence et trafic), si ces résultats sont corrects (erreurs), et si le matériel peut traiter les demandes entrantes (saturation). Ainsi associées, les quatre Golden Signals ont bien leur utilité dans une architecture IT moderne.