🤓 🌤️ 🌯 Observabilité SRE: espaces de noms et structure métrique 🔅 🦅 🌜

Spyglass par Shorai-san

Les espaces de noms métriques structurés sont importants pour un accès rapide aux informations lors d'incidents. Planifiez soigneusement les noms et les dimensions métriques pour prendre en charge un large éventail de requêtes et d'extensions. Une façon efficace de créer un modèle métrique flexible consiste à les considérer comme un arbre.

Cela offre plusieurs avantages: afficher certains sous-ensembles de données, définir une métrique en fonction de ses enfants et établir des relations entre les métriques. Mail.ru Cloud Solutions

Team Article traduit , qui traite des propriétés des espaces de noms de métriques, vous permettant d'augmenter progressivement le détail des requêtes et de passer à des sous-ensembles de données, ainsi que de visualiser la métrique du point de vue des métriques qui la composent. Beaucoup de ces concepts vous sont familiers, car ils sont mis en œuvre dans des solutions de surveillance cloud natives telles que Prometheus et DogStatsD.

Espaces de noms métriques et leur structure

Les espaces de noms métriques sont les espaces conceptuels dans lesquels vivent les métriques. Ils sont souvent limités à une base de données ou un compte:

L'espace de noms des métriques est également la structure des métriques au sein de l'espace de noms. Le nom et la structure appropriés offrent de nombreux avantages énormes.

L'espace de noms dans le diagramme ci-dessus n'a pas de structure explicite. Chaque métrique est séparée et indépendante. Les métriques n'ont rien en commun, sauf le fait qu'elles existent dans le même espace de noms. Dans cette structure indépendante, chaque métrique sera utilisée individuellement. Pour voir la fréquence des demandes http pour un service, la métrique de service doit être accessible directement - service_N_http_requests_total.

Supposons que nous voulons voir le nombre total de demandes à tous les services. Que se passe-t-il dans l'exemple ci-dessus si nous créons un nouveau service?

Si le nombre total de demandes est calculé en additionnant les demandes à service_1 et service_2, l'ajout de service_3 ne modifie pas le nombre total de demandes. Pour calculer le nombre total correct de demandes, vous devez modifier la règle de comptage en ajoutant service_3_http_requests_total. Jetez un œil au graphique du nombre de demandes ci-dessous:

Arborescence des métriques

Une alternative à un espace de noms sans structure consiste à accepter une structure explicite utilisant le nom de la métrique comme espace de noms. Dans le diagramme ci-dessous, vous voyez cette structure comme un arbre:

Dans Prometheus et Datadog, une structure métrique est créée à l'aide de balises et de balises . Les balises vous permettent de construire une arborescence de manière dynamique: chaque fois qu'un nouveau service est ajouté, il fait référence à la métrique racine.

Dans Prometheus, le nombre de demandes par seconde pour tous les services peut être visualisé en créant une demande, comme dans l'image ci-dessous:

Avec un espace de noms structuré, vous pouvez calculer dynamiquement la somme des requêtes sur l'ensemble du nœud. Dans ce cas, Prometheus calcule le nombre de demandes par seconde pour chaque service comme une métrique distincte.

Définition des métriques d'héritage

Lorsque vous utilisez l'arborescence des métriques, chaque dimension métrique (intitulée «service») contient un taux de demande individuel pour un service particulier. En utilisant l'espace de noms des métriques, vous pouvez obtenir non seulement la fréquence totale des demandes, mais également la fréquence des demandes pour chaque service:

À l'aide de l'espace de noms, vous pouvez sélectionner et visualiser non seulement les données de métrique générale, mais également les données de la partie de la métrique générale, regroupées par un attribut. Ainsi, dans l'image ci-dessus, la fréquence des demandes de services individuels est visible, leur somme donne la fréquence des demandes au nœud.

Réduire l'échantillon - sous-ensembles de données

Les espaces de noms prennent également en charge le rétrécissement des requêtes pour récupérer des sous-ensembles spécifiques de données. Par exemple, posons la question: «Quel est le délai p99 (99% des demandes sont plus rapides que le délai spécifié) dans toutes les demandes HTTP réussies pour les serveurs avec déploiement canari?».

L'arbre ci-dessus modélise le concept d'un espace de noms et modélise éventuellement la façon dont les métriques sont stockées sur le disque. L'utilisation d'un espace de noms de métrique bien défini vous permet d'étendre les métriques à n'importe quel paramètre.

L'image ci-dessous montre un graphique de p99 et p50 à partir de l'arbre de mesures ci-dessus:

Si vous faites une demande plus spécifique, vous pouvez, par exemple, répondre à la question suivante: "Quel est le délai p99 dans toutes les demandes HTTP réussies pour les serveurs avec déploiement canari dans le contexte de chaque serveur?"

Ci-dessous, une visualisation d'une métrique avec une sélection par machine_id:

Étant donné que la métrique a une structure bien définie, nous pouvons sélectionner les données nécessaires à partir de la métrique de niveau supérieur en spécifiant les critères de sélection nécessaires - dans notre cas, machine_id.

Règle des cotes

Les coefficients sont une autre façon de structurer les données (corrélations). Il s'agit d'un mécanisme très puissant et de la base de calcul de la disponibilité et du taux d'erreur des SLO (ces indicateurs ont été popularisés par les experts de Google SRE).

Les coefficients permettent à l'utilisateur final d'associer explicitement des métriques, établissant une structure métrique. Ces relations sont le plus souvent exprimées en pourcentage, c'est-à-dire que l'accessibilité peut être calculée comme le rapport «demandes réussies / nombre total de demandes» et le taux d'erreur en «nombre d'erreurs / nombre total de demandes». Un autre exemple de coefficient est la fréquence à laquelle un état provient de plusieurs états.

Illustrons cela et supposons qu'il existe une application qui a exécuté la demande, et la demande pourrait conduire à l'un des deux états: données extraites du cache (cache_hit: true) ou données extraites de la source principale (cache_hit: false). Pour voir le taux d'accès au cache, les données doivent être structurées comme suit:

Le graphique ci-dessous montre la fréquence du cache hit and miss. Chaque demande obtient ou n'entre pas dans le cache. Au total, environ 160 requêtes par seconde se produisent:

Le graphique suivant montre le taux d'accès au cache par rapport au nombre total de demandes. Le coefficient de réussite est de 0,5 (50%):

Vous pouvez donc associer deux métriques. Dans Datadog et Prometheus, cette relation s'exprime par une simple opération arithmétique.

Réponses aux questions par les données

Il est important de réfléchir aux questions auxquelles les données doivent répondre. Dans le tout premier exemple, l'échantillonnage des données ne peut pas répondre exactement à la question: «Combien de requêtes par seconde toutes les instances traitent-elles?», Mais l'arborescence de l'espace de noms aiderait à obtenir la réponse.

Un autre cas courant est l'espace de noms des métriques client avec le nom du service et non avec le nom de la bibliothèque client. L'ajout du nom de la bibliothèque cliente à l'espace de noms répondra à la question: «Le nombre total de demandes de tous les clients?».

Des questions générales utiles répondent aux quatre signaux d'or de Google . Chaque question est posée de manière générale, puis elle est précisée:

Combien de demandes font tous les clients au total?
Combien de demandes chaque client fait-il?
Combien de demandes chaque client fait-il à chaque nœud?
Quel est le pourcentage de demandes de serveur réussies pour chaque RPC?

La même stratégie s'applique aux retards, aux taux d'erreur et à la saturation des ressources.

Mesures génériques balisées

Voici ce que j'ai lu dans les meilleures pratiques pour l'optimisation des requêtes et le stockage des données pour Datadog et Prometheus.

Pour obtenir une vue globale qui prend en charge les détails de segments spécifiques, commencez par un espace de noms supérieur commun et ajoutez des balises et des étiquettes (commencez par des espaces communs, puis ajoutez des espaces plus spécifiques). Pour ce faire, tenez compte de la recommandation ci-dessous.

Méfiez-vous de la cardinalité

Datadog et Prometheus recommandent tous deux de limiter le nombre de balises. Pour citer le manuel Prometheus :

, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

Si vous ajoutez des quotas FS par utilisateur, vous atteindrez rapidement des dizaines de millions de séries chronologiques à partir de 10 000 utilisateurs pour 10 000 nœuds. C'est trop pour l'implémentation actuelle de Prometheus. Même avec des chiffres inférieurs, vous n'aurez plus d'autres indicateurs, potentiellement plus utiles, dans ce suivi.

Commencez sans balises et ajoutez plus de balises au fil du temps si nécessaire.

Une surveillance pratique au niveau de l'utilisateur est souvent mieux réalisée grâce au traçage distribué . Le suivi distribué a son propre espace de métriques et ses meilleures pratiques.

Conclusion

Il est important de comprendre à quelles questions on peut répondre en structurant les métriques. Une structure incorrecte entraîne des difficultés à obtenir des réponses. Bien que la structuration de l'espace métrique ne soit pas compliquée, elle nécessite une planification préalable pour tirer le meilleur parti des données.

Lorsque des problèmes surviennent, la possibilité d'étendre manuellement la métrique pour voir tous les états est critique, et il est important que l'espace de noms n'interfère pas avec cela.

Bonne chance!

Quoi d'autre à lire :

Observabilité SRE: espaces de noms et structure métrique