Résumé de la pratique des indicateurs Prometheus, suivi complet

Quelques pratiques d'utilisation de Promethues pour mettre en œuvre la surveillance des applications

Dans cet article, nous expliquons comment utiliser Prometheus pour surveiller les applications. Dans les travaux ultérieurs, au fur et à mesure que la surveillance s'approfondissait, nous avons résumé certaines pratiques de Metrics sur la base de notre propre expérience et de documents officiels. J'espère que ces pratiques pourront vous fournir une référence.

Déterminer les objets de surveillance

Avant de concevoir les Metrics, il faut d’abord clarifier les objets à mesurer. Ce qui doit être mesuré doit être déterminé en fonction du contexte spécifique du problème, des exigences et du système lui-même qui doit être surveillé.

Partir des besoins

Sur la base de l'expérience d'un grand nombre de surveillances distribuées, Google a résumé quatre indicateurs d'or pour la surveillance . Ces quatre indicateurs ont une bonne signification de référence pour les objets généraux de surveillance et de mesure. Ces quatre indicateurs sont :

• Latence : le temps nécessaire pour répondre à une demande.

• Volume de trafic : surveille le trafic actuel du système et est utilisé pour mesurer les besoins en capacité du service.

• Erreurs : surveillez toutes les demandes d'erreur qui se produisent dans le système actuel et mesurez le taux d'erreurs dans le système actuel.

• Saturation : Mesure la saturation du service actuel. L'accent principal est mis sur les ressources restreintes qui affectent le plus l'état du service. Par exemple, si le système est principalement affecté par la mémoire, concentrez-vous principalement sur l'état de la mémoire du système.

Les quatre indicateurs ci-dessus visent en réalité à répondre aux quatre exigences de suivi :

• Refléter l'expérience utilisateur et mesurer les performances de base du système . Tels que : le retard du système en ligne, le temps d'achèvement du travail du système informatique de travail, etc.

• Reflète le débit du système . Tels que : le nombre de requêtes, la taille des paquets réseau envoyés et reçus, etc.

• Aide à découvrir et à localiser les défauts et les problèmes . Tels que : le nombre d’erreurs, le taux d’échec des appels, etc.

• Reflète la saturation et la charge du système . Tels que : la mémoire occupée par le système, la longueur de la file d'attente des tâches, etc.

En plus des exigences conventionnelles ci-dessus, selon des scénarios de problèmes spécifiques, afin d'éliminer et de découvrir des problèmes survenus ou susceptibles de survenir auparavant, les objets de mesure correspondants peuvent être déterminés. Par exemple, l'interface d'une bibliothèque que le système doit appeler fréquemment peut prendre beaucoup de temps ou échouer occasionnellement. Des métriques peuvent être formulées pour mesurer le délai et le nombre d'échecs de cette interface.

Commencez par le système qui doit être surveillé

Afin de répondre aux exigences correspondantes, différents systèmes doivent observer différents objets de mesure. Dans la meilleure pratique des documents officiels, les candidatures qui doivent être surveillées sont divisées en trois catégories :

• Systèmes de service en ligne (Systèmes de service en ligne) : nécessité de répondre immédiatement à la demande, et l'initiateur de la demande attendra la réponse. Tel qu'un serveur Web.

• Traitement hors ligne : l'auteur de la demande n'attend pas de réponse et le travail demandé prend généralement beaucoup de temps. Tels que le framework de calcul par lots Spark, etc.

• Travaux par lots : Ce type d'application est généralement ponctuelle, ne s'exécute pas tout le temps et se termine une fois l'opération terminée. Tels que les tâches MapReduce pour l'analyse des données.

Pour chaque type d’application, les objets habituellement mesurés ne sont pas les mêmes. Son résumé est le suivant :

• Système de service en ligne : comprend principalement le nombre de demandes, les erreurs, le délai de demande, etc.

• Système informatique hors ligne : l'heure à laquelle la tâche a été traitée pour la dernière fois, le nombre de tâches en cours de traitement, le nombre d'éléments envoyés, la longueur de la file d'attente des tâches, etc.

• Travail de traitement par lots : le dernier moment d'exécution réussi, le temps d'exécution de chaque étape principale, la durée totale, le nombre d'enregistrements traités, etc.

En plus du système lui-même, il est parfois nécessaire de surveiller des sous-systèmes :

• Bibliothèques utilisées : nombre d'appels, nombre de réussites, nombre d'erreurs, délai d'appel.

• Journalisation : comptez chaque journal écrit afin de pouvoir trouver la fréquence et l'heure de chaque journal.

• Échecs : nombre d’erreurs.

• Pool de threads : nombre de requêtes en file d'attente, nombre de threads utilisés, nombre total de threads, chronophage, nombre de tâches en cours de traitement, etc.

• Cache : nombre de requêtes, nombre de hits, délai total, etc.

Sélectionnez un vecteur

Principes de choix de Vec :

• Types de données similaires mais types de ressources, emplacements de collecte différents, etc.

• Les unités de données dans Vec sont unifiées

exemple:

• Délais de demande pour différents objets de ressources

• Retards de demande pour les serveurs dans différentes régions

• Nombre d’erreurs de requête http différentes
  …

De plus, le document officiel suggère que pour différentes opérations d'un objet ressource, telles que la lecture/écriture, l'envoi/réception, différentes métriques doivent être utilisées pour enregistrer au lieu d'être placées dans une seule métrique. La raison en est que les deux ne sont généralement pas regroupés lors du suivi, mais observés séparément.

Cependant, pour la mesure de la demande, Label est généralement utilisé pour distinguer différentes actions.

Confirmer l'étiquette

Les options d'étiquette courantes sont :

• Ressource

• région

• tapez
  …

Un principe important pour déterminer Label est le suivant : les données de Label dans la même dimension peuvent être moyennées et additionnées, c'est-à-dire que les unités doivent être unifiées. Par exemple, la vitesse et la tension du ventilateur ne peuvent pas être placées dans une étiquette.

De plus, les pratiques suivantes ne sont pas recommandées :

my_metric{label=a} 1 my_metric{label=b} 6 my_metric{label=total} 7

C'est-à-dire que le score et les données totales sont comptés dans l'étiquette. Il est recommandé d'utiliser PromQL pour agréger côté serveur afin d'obtenir le résultat total. Ou utilisez une autre métrique pour mesurer les données globales.

Nommer les métriques et les étiquettes

Un bon nom peut être vu et compris, donc le nom fait également partie d’une bonne conception.

Dénomination des métriques :

• Doit correspondre au motif : a-zA-Z :

• Doit contenir un mot comme préfixe indiquant le domaine auquel appartient cette métrique.

  comme:

  • prometheus_notifications_total

  • processus_cpu_seconds_total

  • ipamd_request_latency

• Doit contenir une unité comme suffixe pour indiquer l'unité de cette métrique.

  comme:

  • http_request_duration_seconds

  • node_memory_usage_bytes

  • http_requests_total (pour un nombre cumulatif sans unité)

• Logiquement la même signification que la variable mesurée.

• Essayez d'utiliser des unités de base telles que les secondes et les octets. Au lieu de millisecondes, des mégaoctets.

Dénomination de l'étiquette :

Nom selon la dimension sélectionnée, tel que :

• Région : Shenzhen/Guangzhou/Pékin

• propriétaire : utilisateur1/utilisateur2/utilisateur3

• étape : extraire/transformer/charger

Sélection de seaux

Des compartiments appropriés peuvent rendre le calcul du centile de l'histogramme plus précis.

Idéalement, les compartiments répartiront les données sous forme d'échelle, c'est-à-dire que le nombre de données dans chaque intervalle de compartiment est à peu près le même.
La conception des godets peut suivre l’expérience suivante :

• Vous devez connaître la distribution approximative des données. Si vous ne la connaissez pas à l'avance, vous pouvez utiliser le bucket par défaut ({.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}) ou 2 Plusieurs compartiments ({1,2,4,8…}) observent la distribution des données, puis ajustent les compartiments.

• Lorsque la distribution des données est dense, l'intervalle de compartiment peut être défini plus étroit, et lorsque la distribution des données est clairsemée, l'intervalle de compartiment peut être défini plus large.

• Pour la plupart des données de retard, qui présentent généralement des caractéristiques de longue traîne, il est plus approprié d'utiliser des compartiments exponentiels (ExponentialBuckets).

• La limite supérieure initiale du compartiment couvre généralement environ 10 % des données. Si vous ne faites pas attention aux données d'en-tête, vous pouvez augmenter la limite supérieure initiale.

• Si vous souhaitez calculer avec plus de précision un centile spécifique, tel que 90 %, vous pouvez chiffrer le compartiment de distribution à 90 % des données, c'est-à-dire réduire l'intervalle du compartiment.

Par exemple, lorsque je surveille la durée de certaines de nos tâches, je choisis d'estimer la valeur approximative du bucket en fonction de la situation réelle, puis d'ajuster le bucket après avoir observé les données et surveillé après la mise en ligne. doit être ajusté à une valeur plus appropriée après plusieurs ajustements.

Conseils d'utilisation du Grafana

Afficher toutes les dimensions

Si vous souhaitez savoir si vous pouvez regrouper par d'autres dimensions et vérifier rapidement quelles autres dimensions sont disponibles, vous pouvez utiliser la technique suivante : conserver uniquement le nom de l'index dans l'expression de la requête, n'effectuer aucun calcul et laisser la Légende formater vide. Cela affichera les données métriques brutes. Comme indiqué ci-dessous

Liaison de règle

Dans le panneau Paramètres, il existe un élément de paramètre Info-bulle graphique, qui utilise Par défaut par défaut.

Ensuite, ajustez les outils d’affichage graphique sur Réticule partagé et Info-bulle partagée respectivement pour voir l’effet. Vous pouvez voir que les règles peuvent être affichées conjointement, ce qui facilite la confirmation de la corrélation entre les deux indicateurs lors du dépannage.

Ajustez l'outil d'affichage graphique sur Info-bulle partagée :

Source : https://lxkaka.wang/metrics-best-practice/#grafana-%E4%BD%BF%E7%94%A8%E6%8A%80%E5%B7%A7