Collecte de métriques à partir de votre infrastructure et de vos applications

Comprendre l’état de vos systèmes est essentiel pour assurer la fiabilité et la stabilité de vos applications et services. Les informations sur la santé et les performances de vos déploiements aident non seulement votre équipe à réagir aux problèmes, mais leur procurent également la sécurité nécessaire pour apporter des modifications en toute confiance. L’un des meilleurs moyens d’obtenir cette information consiste à utiliser un système de surveillance robuste qui rassemble des métriques, visualise des données et alerte les opérateurs lorsque quelque chose semble cassé.

Dans notre introduction à la métrique, à la surveillance et à notre guide d’alerte, nous avons abordé certains des concepts de base impliqués dans logiciel de surveillance et infrastructure. Les métriques constituent le principal matériau traité par les systèmes de surveillance pour créer une vue cohérente des systèmes suivis. La première étape de la conception d’un système capable de fournir des informations fiables et exploitables sur l’état de vos logiciels et de votre matériel est de savoir quels composants valent la peine d’être surveillés et quelles sont les caractéristiques spécifiques que vous devriez examiner.

Dans ce guide, nous commencerons par examiner un cadre populaire utilisé pour identifier les indicateurs les plus critiques à suivre. Nous verrons ensuite comment ces indicateurs peuvent être appliqués aux composants tout au long de votre déploiement. Ce processus se concentrera d’abord sur les ressources fondamentales des serveurs individuels, puis ajustera la portée pour couvrir des domaines de préoccupation de plus en plus vastes.

Dans le livre très influent https://landing.google.com/sre/book.html[Google SRE (ingénierie de la fiabilité des sites), le chapitre sur la surveillance des systèmes distribués introduit un cadre utile appelé * quatre signaux en or de la surveillance * qui représente les facteurs les plus importants à mesurer dans un système orienté utilisateur. Nous aborderons chacune de ces quatre caractéristiques ci-dessous.

En vous guidant sur les quatre signaux d’or, vous pouvez commencer à regarder comment ces métriques seraient exprimées dans la hiérarchie de vos systèmes. Étant donné que les services sont souvent créés en ajoutant des couches d’abstraction au-dessus de composants plus fondamentaux, les métriques doivent être conçues pour ajouter des informations à chaque niveau du déploiement.

Nous examinerons différents niveaux de complexité présents dans les environnements d’application distribués courants:

L’ordre ci-dessus étend l’étendue et le niveau d’abstraction avec chaque couche suivante.

Les mesures de niveau de base qu’il est important de collecter sont celles qui concernent les ordinateurs sous-jacents sur lesquels vos systèmes reposent. Bien que des efforts considérables soient déployés dans le développement de logiciels modernes pour résumer les composants physiques et les détails des systèmes d’exploitation de bas niveau, chaque service dépend du matériel et des systèmes d’exploitation sous-jacents. Pour cette raison, garder un œil sur les ressources fondamentales de vos machines est la première étape pour bien comprendre la santé de vos systèmes.

Lorsque vous envisagez les métriques à collecter au niveau de la machine, pensez aux ressources individuelles disponibles. Celles-ci incluront des représentations du matériel de votre serveur ainsi que des abstractions principales fournies par le système d’exploitation, telles que les processus et les descripteurs de fichiers. En regardant chaque composante en termes des quatre signaux d’or, certains signaux peuvent être évidents alors que d’autres peuvent être plus difficiles à raisonner.

http://www.brendangregg.com [Brendan Gregg], un ingénieur influent en performances, décrit de nombreuses manières d’obtenir des métriques de base des systèmes Linux pour répondre aux besoins d’un framework qu’il appelle le http://www.brendangregg.com/usemethod. .html [Méthode USE pour l’analyse de la performance] ( u tilization, s aturation, and e rrors). Comme il existe un important chevauchement entre la méthode USE et les quatre signaux d’or, nous pouvons utiliser certaines de ses recommandations comme point de départ pour déterminer les données à collecter à partir des composants du serveur.

Pour mesurer * CPU *, les mesures suivantes peuvent être appropriées:

Pour * mémoire *, les signaux pourraient ressembler à ceci:

Pour * périphériques de stockage *:

Les signaux * réseau * peuvent ressembler à ceci:

Parallèlement aux représentations des ressources physiques, il est également judicieux de rassembler des mesures relatives aux abstractions de système d’exploitation dont les limites sont appliquées. Quelques exemples qui entrent dans cette catégorie sont les descripteurs de fichiers et les nombres de threads. Ce ne sont pas des ressources physiques, mais des constructions avec des plafonds définis par le système d’exploitation pour empêcher les processus de se prolonger excessivement. La plupart peuvent être ajustés et configurés avec des commandes telles que + ulimit +, mais le suivi des modifications de l’utilisation de ces ressources peut vous aider à détecter les modifications potentiellement néfastes de l’utilisation de votre logiciel.

En remontant d’une couche, nous commençons à traiter les applications et les services exécutés sur les serveurs. Ces programmes utilisent les composants de serveur individuels traités précédemment comme ressources pour fonctionner. Les métriques de ce niveau nous aident à comprendre la santé de nos applications et services à hôte unique. Nous avons séparé les services multi-hôtes distribués dans une section distincte afin de clarifier les facteurs les plus importants dans ces configurations.

Alors que les métriques de la dernière section détaillaient les capacités et les performances de composants individuels et du système d’exploitation, les métriques ici nous diront dans quelle mesure les applications sont capables de réaliser le travail que nous leur demandons. Nous voulons également savoir de quelles ressources reposent nos applications et dans quelle mesure elles gèrent ces contraintes.

Il est important de garder à l’esprit que les métriques de cette section représentent une rupture avec l’approche généralisée que nous avons pu utiliser la dernière fois. Les indicateurs les plus importants à partir de maintenant dépendront beaucoup des caractéristiques de vos applications, de votre configuration et des charges de travail que vous exécutez sur vos ordinateurs. Nous pouvons discuter des moyens d’identifier vos indicateurs les plus importants, mais vos résultats dépendront de ce que le serveur est spécifiquement invité à faire.

Pour les applications destinées aux clients, les quatre signaux d’or sont souvent assez simples à identifier:

Certains des indicateurs les plus importants que vous souhaiterez suivre sont ceux liés aux dépendances. Celles-ci seront souvent mieux exprimées par des mesures de saturation liées à des composants individuels. Par exemple, l’utilisation de la mémoire des applications, les connexions disponibles, le nombre de descripteurs de fichiers ouverts ou le nombre de travailleurs actifs peuvent vous aider à comprendre l’effet de votre configuration appliquée dans le contexte du serveur physique.

Les quatre signaux principaux ont été conçus principalement pour les microservices distribués. Ils reposent donc sur une architecture client-serveur. Pour les applications qui n’utilisent pas une architecture client-serveur, les mêmes signaux sont toujours importants, mais le signal «trafic» peut devoir être légèrement revu. Il s’agit essentiellement d’une mesure de l’activité professionnelle. Par conséquent, la recherche d’une métrique qui représente de manière adéquate votre application servira le même objectif. Les détails dépendront de ce que fait votre programme, mais certains substituts généraux pourraient être le nombre d’opérations ou de données traitées par seconde.

La plupart des services, en particulier lorsqu’ils sont utilisés dans un environnement de production, couvrent plusieurs instances de serveur afin d’accroître les performances et la disponibilité. Ce niveau de complexité accru ajoute une surface supplémentaire qu’il est important de surveiller. L’informatique distribuée et les systèmes redondants peuvent rendre vos systèmes plus flexibles, mais la coordination basée sur le réseau est plus fragile que la communication au sein d’un hôte unique. Une surveillance robuste peut aider à atténuer certaines des difficultés liées à l’utilisation d’un canal de communication moins fiable.

Au-delà du réseau lui-même, pour les services distribués, la santé et les performances du groupe de serveurs sont plus importantes que les mêmes mesures appliquées à un hôte individuel. Alors que les services sont intimement liés à l’ordinateur sur lequel ils s’exécutent lorsqu’ils sont confinés à un seul hôte, les services multi-hôtes redondants reposent sur les ressources de plusieurs hôtes tout en restant découplés de la dépendance directe à un ordinateur.

Les signaux en or à ce niveau sont très similaires à ceux qui mesurent la santé du service dans la dernière section. Ils prendront toutefois en compte la coordination supplémentaire requise entre les membres du groupe:

Bien que ceux-ci aient une ressemblance évidente avec les métriques importantes pour les services à hôte unique, la complexité de chacun des signaux augmente lorsqu’elle est distribuée. La latence devient un problème plus complexe car le traitement peut nécessiter une communication entre plusieurs hôtes. Le trafic n’est plus fonction des capacités d’un seul serveur, mais bien d’un résumé des capacités des groupes et de l’efficacité de l’algorithme de routage utilisé pour répartir le travail. Des modes d’erreur supplémentaires sont introduits liés à la connectivité réseau ou à l’échec de l’hôte. Enfin, la saturation s’étend pour inclure les ressources combinées disponibles pour les hôtes, le lien réseau reliant chaque hôte et la possibilité de coordonner correctement l’accès aux dépendances dont chaque ordinateur a besoin.

Certaines des mesures les plus précieuses à collecter existent à la frontière de votre application ou de votre service, en dehors de votre contrôle direct. Les dépendances externes, y compris celles liées à votre fournisseur d’hébergement et à tous les services sur lesquels vos applications sont conçues pour pouvoir compter. Celles-ci représentent des ressources que vous n’êtes pas en mesure d’administrer directement, mais qui peuvent compromettre votre capacité à garantir votre propre service.

Étant donné que les dépendances externes représentent des ressources critiques, l’une des seules stratégies d’atténuation disponibles en cas de panne complète consiste à transférer les opérations vers un autre fournisseur. Il ne s’agit là que d’une stratégie viable pour les produits de base, et même dans ce cas uniquement avec une planification préalable et un couplage lâche avec le fournisseur. Même lorsque l’atténuation est difficile, la connaissance des événements externes affectant votre application est extrêmement utile.

Les signaux dorés appliqués aux dépendances externes peuvent ressembler à ceci:

Ces mesures peuvent vous aider à identifier les problèmes liés à vos dépendances, à vous alerter de l’épuisement imminent des ressources et à maîtriser les dépenses. Si le service dispose d’alternatives directes, ces données peuvent être utilisées pour décider de déplacer un travail vers un autre fournisseur lorsque les métriques indiquent qu’un problème se produit. Pour les situations avec moins de flexibilité, les métriques peuvent au moins être utilisées pour alerter un opérateur et lui permettre de réagir à la situation et de mettre en œuvre toutes les options d’atténuation manuelles disponibles.

Les métriques de niveau le plus élevé suivent les demandes via le système dans le contexte du composant le plus externe avec lequel les utilisateurs interagissent. Il peut s’agir d’un équilibreur de charge ou d’un autre mécanisme de routage chargé de recevoir et de coordonner les demandes adressées à votre service. Etant donné que ceci représente le premier point de contact avec votre système, la collecte de métriques à ce niveau donne une idée approximative de l’expérience utilisateur globale.

Bien que les métriques décrites précédemment soient incroyablement utiles, les métriques de cette section sont souvent les plus importantes pour la configuration des alertes. Pour éviter la fatigue des réponses, les alertes, en particulier les pages, doivent être réservées aux scénarios ayant un effet négatif reconnaissable sur l’expérience de l’utilisateur. Les problèmes rencontrés avec ces métriques peuvent être étudiés en explorant à l’aide des métriques collectées à d’autres niveaux.

Les signaux que nous recherchons ici sont similaires à ceux des services individuels décrits précédemment. La principale différence réside dans la portée et l’importance des données que nous recueillons ici:

Comme ces mesures sont parallèles aux demandes des utilisateurs, les valeurs situées en dehors des plages acceptables pour ces mesures indiquent probablement un impact direct sur l’utilisateur. Une latence qui n’est pas conforme aux accords sur les niveaux de service internes ou internes (accord sur les niveaux de service), le trafic qui indique une forte augmentation ou une chute importante, l’augmentation du taux d’erreur et l’incapacité de répondre aux demandes en raison de contraintes de ressources sont assez simples à expliquer. à ce niveau. En supposant que les métriques soient exactes, les valeurs ici peuvent être directement associées à vos objectifs de disponibilité, de performance et de fiabilité.

Dans ce guide, nous avons d’abord abordé les quatre signaux d’or qui sont généralement les plus utiles pour découvrir et comprendre les changements qui ont un impact sur vos systèmes. Nous avons ensuite utilisé les signaux comme une lentille pour évaluer les facteurs les plus importants à suivre sur différentes couches d’un déploiement.

L’évaluation de vos systèmes de haut en bas peut aider à identifier les composants et les interactions critiques nécessaires à l’exécution de services fiables et performants. Les quatre signaux en or peuvent constituer un excellent point de départ pour structurer les métriques afin de mieux indiquer la santé de vos systèmes. Cependant, gardez à l’esprit que, si les signaux d’or constituent un bon cadre, vous devrez connaître d’autres paramètres spécifiques à votre situation. Recueillez toutes les données susceptibles, selon vous, de vous mettre en garde contre les problèmes ou de vous aider à résoudre les problèmes qui surviennent.