Que vous soyez un DevOps, un SRE ou simplement une personne axée sur les données, vous êtes probablement accro aux tableaux de bord et aux métriques. Nous examinons nos mesures pour voir comment notre système fonctionne, que ce soit au niveau de l'infrastructure, de l'application ou de l'entreprise. Nous faisons confiance à nos mesures pour nous montrer l'état de notre système et où il se comporte mal. Mais nos mesures nous montrent-elles ce qui s'est réellement passé ? Vous seriez surpris de voir combien de fois ce n'est pas le cas.

Dans cet article, j'examinerai les mathématiques et les mécanismes derrière les métriques, certaines idées fausses courantes, ce qu'il faut pour avoir des métriques précises et s'il existe même une telle chose.

L'essentiel des métriques

Les métriques sont essentiellement des cumuls d'événements bruts. Au cours de ce processus de cumul, les événements sont traduits en points de données numériques. Un exemple simple est celui des erreurs qui se produisent dans le système, avec une métrique simple pour compter les erreurs. Les métriques peuvent également impliquer plusieurs variables, telles qu'un nombre de requêtes avec un temps de réponse supérieur à 1 seconde. Lorsqu'ils sont mesurés dans le temps, ces points de données forment une série chronologique .

Les métriques peuvent être de différents types, tels que des compteurs, des jauges et des histogrammes. Les compteurs sont utilisés pour le comptage cumulé des événements, comme nous l'avons vu dans les exemples ci-dessus. Les jauges représentent généralement la dernière valeur de mesure. Et puis il existe des types plus élaborés tels que les histogrammes qui peuvent échantillonner la distribution des valeurs métriques, en comptant les événements dans des « buckets » ou « bins » configurables. Par exemple, vous souhaiterez peut-être comprendre le pourcentage d'utilisation de la mémoire segmenté par les pods de votre cluster à des moments donnés.

La mécanique des métriques

Dans un monde idéal, nous ingérerions et stockerions tous les événements bruts, puis calculerions les métriques au moment de la requête. Cela nous permettrait de découper et de découper les événements de la manière dont nous avons besoin et de poser toutes les questions ad hoc que nous désirons.

Dans le monde réel, cependant, la conservation de tous les événements bruts pendant de longues périodes peut être extrêmement coûteuse, en raison des volumes élevés de données. Pour surmonter cela, les événements sont fréquemment regroupés en métriques dans le pipeline de collecte, tout en supprimant les événements bruts ou en les conservant pendant de courtes périodes uniquement. Il s'agit souvent d'une simple configuration dans votre agent collecteur de métriques.

En plus de réduire les coûts, l'agrégation lors de la collecte peut améliorer les performances des analyses en temps réel avec des taux de transmission et d'ingestion de métriques plus élevés à une fréquence plus élevée, et en évitant les agrégations et les calculs lourds au moment de la requête.

Le calcul des métriques en bref

Ce processus de cumul implique quelques calculs. Nous pourrions vouloir calculer la moyenne ou la médiane des temps de réponse, ou peut-être un centile, ou une agrégation sur une fenêtre temporelle. Nous pouvons également souhaiter regrouper plusieurs événements dans une seule métrique composite. Par exemple, je peux vouloir calculer le 95e centile (communément appelé P95) de tous les pods d'un service spécifique dans mon cluster.

Même si vous n'aimez pas les maths, vous ne pouvez pas les éviter avec les métriques. Vous devez comprendre les différentes fonctions d'agrégation et la relation entre la question que vous souhaitez poser et la métrique et l'agrégat dont vous avez besoin pour y répondre. Prenons l'exemple de la fonction Moyenne, car beaucoup ont tendance à commencer par là. Les moyennes, par définition, lissent les choses et seront moins adaptées pour éliminer les comportements anormaux et les valeurs aberrantes. Lorsque vous enquêtez sur des problèmes de latence, par exemple, il sera tout à fait inutile de regarder les valeurs métriques moyennes, et vous feriez mieux de regarder les centiles.

Déterminez vos questions, concevez vos métriques en conséquence

D'une certaine manière, vous pouvez considérer ces métriques comme une compression avec perte, au cours de laquelle nous perdons des données et le contexte des événements bruts. Si nous ne gardons pas les événements bruts, nous devons déterminer dès le départ ce qui est important pour nous. Par exemple, si je ne calcule que la valeur moyenne sur les données, je ne pourrai pas poser de questions sur le P95 (95e centile) plus tard sur les données pré-agrégées.

Vous devez déterminer les questions auxquelles vous souhaitez répondre, ce qui est important pour vous, et concevoir vos métriques et agrégations en conséquence. Une erreur courante est que les gens évitent cette phase de conception et utilisent simplement les métriques prédéfinies et les valeurs par défaut fournies avec le collecteur de métriques de leur choix. Bien que vous puissiez penser que ces valeurs par défaut représentent certaines normes de l'industrie, elles sont souvent assez héritées et, dans la plupart des cas, ne seront pas en phase avec vos besoins spécifiques.

Le problème de la mesure

Tout comme en physique, le problème de mesure se produit lorsque nous mesurons une propriété (apparemment) continue à des intervalles discrets, souvent appelés l' intervalle d'échantillonnage , qui détermine le taux d'échantillonnage. Cela crée une représentation déformée, où la métrique peut ne pas refléter réellement la propriété mesurée à l'origine. Par exemple, si nous mesurons l'utilisation du processeur toutes les 60 secondes, toute valeur aberrante du processeur se produisant entre ces points d'échantillonnage nous sera invisible.

De plus, pour tracer une ligne consécutive, les outils de visualisation effectuent souvent une moyenne sur des points de données consécutifs, ce qui donne l'apparence trompeuse d'une ligne lisse. À certaines occasions, l'inverse peut se produire, où vous pouvez obtenir des artefacts dans vos métriques qui ne sont pas réels, comme des pics dans vos métriques qui n'existent pas vraiment. Cela peut se produire lors de l'exécution d'agrégations dans le backend de stockage, en raison de l'emplacement dans lequel le calcul est effectué.

Temps moyen de détection

La période d'échantillonnage influence également la vitesse à laquelle un changement dans le système sera visible dans les métriques. La plupart des algorithmes nécessitent cinq points de données pour détecter une tendance. Si l'intervalle d'échantillonnage est de 60 secondes, le calcul simple détermine qu'il faudra cinq minutes (c'est-à-dire 60 secondes X 5 points de données) avant de voir que quelque chose ne va pas. Pourriez-vous vous permettre d'attendre 5 minutes pour savoir que votre système est tombé en panne ? L'utilisation d'intervalles d'échantillonnage plus courts (c'est-à-dire des taux d'échantillonnage plus élevés) raccourcira cette période et nous permettra de détecter et de réagir plus rapidement. Bien sûr, des taux d'échantillonnage plus élevés entraînent une surcharge du processeur et du stockage, nous devons donc trouver la configuration qui trouve le bon équilibre pour nos besoins.

Résolution variable et réduction d'échelle

Une pratique courante consiste à enregistrer les métriques dans différentes résolutions dans une approche à plusieurs niveaux, afin de réduire les coûts. Par exemple, vous souhaiterez peut-être enregistrer la métrique toutes les 10 secondes pour le premier jour, puis toutes les 5 minutes pour la semaine suivante, et peut-être toutes les 1 heure pour le mois ou plus à venir. Cette pratique suppose que nous avons besoin de la granularité la plus fine pour la période en temps quasi réel, ce dont nous pourrions avoir besoin en cas de problème dans le système, tandis que les enquêtes sur des périodes plus longues nécessitent des tendances à plus grande échelle.

Les différentes granularités peuvent être obtenues en réduisant les métriques, à savoir en calculant la métrique la moins granulaire à partir de la granularité la plus élevée. Bien que cela semble parfaitement raisonnable, les mathématiques peuvent interférer ici, car certaines fonctions d'agrégation ne sont pas compatibles avec certains calculs et ne peuvent donc pas être agrégées ultérieurement. Par exemple, les centiles ne sont pas additifs et ne peuvent pas être additionnés. Ainsi, en suivant l'exemple ci-dessus, si vous avez un centile P99 échantillonné avec une résolution de 10 secondes, vous ne pouvez pas les étendre à une résolution de 5 minutes. Il est important de connaître la compatibilité des fonctions d'agrégation et, lors de l'utilisation de fonctions non compatibles telles que les centiles, de prendre des décisions de conception concernant les résolutions dont nous avons besoin et de calculer ces séries temporelles à l'avance.

La résolution variable n'est pas limitée uniquement au facteur temps. Un autre exemple consiste à enregistrer des données par pod, puis à « regrouper par » nœuds ou clusters. La même contrainte s'applique ici, ce qui signifie que si nous nous attendons à être intéressés par le découpage en tranches et en dés d'une métrique basée sur les centiles par nœud, par région, par espace de noms ou sur l'ensemble du cluster, nous devons pré-agréger en conséquence.

Une autre approche consiste à renoncer à la précision des mesures pour gagner en compatibilité dans le calcul, en utilisant des histogrammes. Vous pouvez prendre des histogrammes de quelques serveurs et les résumer, ou des histogrammes de plusieurs fenêtres temporelles et les résumer, puis les réduire. Le problème est que dans ce cas, les centiles seront des estimations plutôt que des précisions. Il est également important de noter que les histogrammes prennent plus de temps en termes de stockage et de débit, car chaque échantillon n'est pas simplement un nombre unique mais quelques échantillons (un par seau).

Sommaire

Les métriques sont un moyen puissant de surveiller nos applications. Mais ils ne sont pas nécessairement représentatifs de l'état réel du système. Cela nécessite une compréhension des mathématiques et de la nature des métriques, ainsi qu'une conception soignée, pour s'assurer que nos métriques sont effectivement utiles pour répondre aux questions dont nous avons besoin. Avoir accès aux données brutes en plus des métriques est toujours bon, car c'est finalement la source de vérité.

Vous voulez en savoir plus ? Découvrez l'épisode OpenObservability Talks : All Metrics Are Wrong, Some Are Useful on Spotify , Apple Podcasts or other podcast apps .

Cet article était à l'origine ici .