Surveillance pour les déploiements distribués et les microservices

Certains des changements les plus fondamentaux dans le comportement de nombreux systèmes sont dus à l’explosion de nouvelles couches d’abstraction autour desquelles les logiciels peuvent être conçus. La technologie de conteneur a changé la relation entre le logiciel déployé et le système d’exploitation sous-jacent. Les applications déployées dans des conteneurs ont des relations différentes avec le monde extérieur, les autres programmes et le système d’exploitation hôte que les applications déployées par des moyens conventionnels. Les abstractions de noyau et de réseau peuvent mener à différentes compréhensions de l’environnement d’exploitation en fonction de la couche que vous vérifiez.

Ce niveau d’abstraction est extrêmement utile à bien des égards en créant des stratégies de déploiement cohérentes, facilitant la migration du travail entre les hôtes et en permettant aux développeurs de contrôler étroitement les environnements d’exécution de leurs applications. Cependant, ces nouvelles fonctionnalités se font au détriment d’une complexité accrue et d’une relation plus distante avec les ressources alimentant chaque processus.

Un point commun entre les paradigmes les plus récents est le recours accru à la communication réseau interne pour coordonner et accomplir les tâches. Ce qui était auparavant le domaine d’une seule application pourrait maintenant être réparti entre de nombreux composants devant coordonner et partager des informations. Cela a quelques répercussions en termes d’infrastructure de communication et de surveillance.

Premièrement, étant donné que ces modèles reposent sur la communication entre de petits services discrets, la santé du réseau devient plus importante que jamais. Dans les architectures traditionnelles plus monolithiques, la coordination des tâches, le partage d’informations et l’organisation des résultats étaient en grande partie réalisés au sein d’applications utilisant une logique de programmation régulière ou par le biais d’une quantité relativement réduite de communications externes. En revanche, le flux logique des applications hautement distribuées utilise le réseau pour se synchroniser, vérifier l’intégrité des homologues et transmettre des informations. L’intégrité et les performances du réseau ont directement un impact sur davantage de fonctionnalités qu’auparavant, ce qui signifie qu’une surveillance plus intensive est nécessaire pour garantir un fonctionnement correct.

Bien que le réseau soit devenu plus critique que jamais, il est de plus en plus difficile de le surveiller efficacement en raison du nombre accru de participants et de lignes de communication individuelles. Au lieu de suivre les interactions entre quelques applications, une communication correcte entre des dizaines, des centaines ou des milliers de points différents devient nécessaire pour garantir la même fonctionnalité. Outre des considérations de complexité, l’augmentation du volume de trafic impose également une charge supplémentaire aux ressources réseau disponibles, aggravant encore la nécessité d’une surveillance fiable.

Nous avons évoqué plus haut la tendance des architectures modernes à répartir le travail et les fonctionnalités entre de nombreux composants plus petits et discrets. Ces conceptions peuvent avoir un impact direct sur le paysage de surveillance car elles rendent la clarté et la compréhensibilité particulièrement utiles, mais de plus en plus difficiles à atteindre.

Un outillage et une instrumentation plus robustes sont nécessaires pour assurer le bon fonctionnement. Cependant, comme la responsabilité de l’achèvement d’une tâche donnée est fragmentée et répartie entre différents travailleurs (potentiellement sur de nombreux hôtes physiques différents), il peut être difficile de comprendre à qui revient la responsabilité des problèmes de performance ou des erreurs. Les demandes et les unités de travail qui touchent des dizaines de composants, dont beaucoup sont sélectionnés parmi des groupes de candidats possibles, peuvent rendre la visualisation du chemin des demandes ou l’analyse des causes profondes impraticables à l’aide de mécanismes traditionnels.

Une autre difficulté à adapter le suivi conventionnel consiste à suivre judicieusement les unités éphémères ou éphémères. Que les unités concernées soient des instances de calcul dans le cloud, des instances de conteneur ou d’autres abstractions, ces composants violent souvent certaines des hypothèses avancées par les logiciels de surveillance classiques.

Par exemple, pour faire la distinction entre un nœud en panne problématique et une instance volontairement détruite, le système de surveillance doit avoir une compréhension plus intime de votre couche de provisionnement et de gestion qu’auparavant. Pour de nombreux systèmes modernes, ces événements se produisent beaucoup plus fréquemment. Il n’est donc pas pratique d’ajuster manuellement le domaine de surveillance. L’environnement de déploiement évoluant plus rapidement avec ces conceptions, la couche de surveillance doit adopter de nouvelles stratégies pour rester utile.

Une question à laquelle de nombreux systèmes doivent faire face est de savoir quoi faire avec les données d’instances détruites. Bien que les unités de travail puissent être configurées et supprimées rapidement pour répondre aux demandes changeantes, il faut décider quoi faire des données relatives aux anciennes instances. Les données ne perdent pas nécessairement leur valeur immédiatement simplement parce que le travailleur sous-jacent n’est plus disponible. Lorsque des centaines ou des milliers de nœuds vont et viennent chaque jour, il peut être difficile de savoir comment construire au mieux une description de la santé opérationnelle globale de votre système à partir des données fragmentées d’instances de courte durée.

L’augmentation du volume total du trafic provoquée par le nombre élevé de services est l’un des problèmes les plus simples à résoudre. Au-delà du nombre croissant de transferts généré par les nouvelles architectures, l’activité de surveillance elle-même peut commencer à saper le réseau et à voler des ressources hôte. Pour gérer au mieux l’augmentation du volume, vous pouvez soit augmenter votre infrastructure de surveillance, soit réduire la résolution des données avec lesquelles vous travaillez. Les deux approches méritent d’être examinées, mais nous allons nous concentrer sur la seconde car elle représente une solution plus extensible et plus largement utile.

La modification de vos taux d’échantillonnage de données peut réduire la quantité de données que votre système doit collecter auprès des hôtes. L’échantillonnage est une partie normale de la collection de mesures qui représente la fréquence à laquelle vous demandez de nouvelles valeurs pour une mesure. L’augmentation de l’intervalle d’échantillonnage réduira la quantité de données que vous devez gérer mais également la résolution (niveau de détail) de vos données. Bien que vous deviez être prudent et comprendre votre résolution minimale utile, modifier les taux de collecte de données peut avoir un impact considérable sur le nombre de clients de surveillance que votre système peut desservir de manière adéquate.

Pour réduire la perte d’informations résultant de résolutions moins élevées, une option consiste à continuer à collecter des données sur les hôtes à la même fréquence, mais en les compilant en nombres plus digestibles pour les transférer sur le réseau. Des ordinateurs individuels peuvent agréger et faire la moyenne des valeurs de mesure et envoyer des résumés au système de surveillance. Cela peut aider à réduire le trafic réseau tout en maintenant la précision, car un grand nombre de points de données sont toujours pris en compte. Notez que cela contribue à réduire l’influence de la collecte de données sur le réseau, mais n’aide pas en soi à réduire les contraintes liées à la collecte de ces chiffres au sein de l’hôte.

Comme mentionné ci-dessus, l’un des principaux facteurs de différenciation entre les systèmes traditionnels et les architectures modernes est la décomposition des composants participant aux demandes de traitement. Dans les systèmes distribués et les microservices, une unité de travail est beaucoup plus susceptible d’être attribuée à un groupe de travailleurs via un type de couche de planification ou d’arbitrage. Cela a des implications sur de nombreux processus automatisés que vous pourriez construire autour de la surveillance.

Dans les environnements qui utilisent des pools de travailleurs interchangeables, les stratégies de vérification de l’état et d’alerte peuvent développer des relations complexes avec l’infrastructure qu’elles surveillent. Les contrôles de santé des travailleurs individuels peuvent être utiles pour mettre hors service et recycler automatiquement les unités défectueuses. Toutefois, si l’automatisation est en place et à grande échelle, peu importe si un seul serveur Web ne parvient pas à sortir d’un grand pool. Le système s’auto-corrigera pour s’assurer que seules les unités en bonne santé se trouvent dans le pool actif recevant les demandes.

Bien que les vérifications de l’état de l’hôte puissent détecter les unités défectueuses, la vérification de l’état du pool lui-même est plus appropriée pour l’alerte. La capacité du pool à satisfaire la charge de travail actuelle influe davantage sur l’expérience utilisateur que les capacités d’un travailleur individuel. Des alertes basées sur le nombre de membres sains, la latence pour l’agrégat de pool ou le taux d’erreur de pool peuvent avertir les opérateurs des problèmes difficiles à atténuer automatiquement et susceptibles d’impacter les utilisateurs.

En général, la couche de surveillance dans les systèmes distribués doit avoir une compréhension plus complète de l’environnement de déploiement et des mécanismes de provisioning. La gestion automatisée du cycle de vie devient extrêmement précieuse en raison du nombre d’unités individuelles impliquées dans ces architectures. Que les unités soient des conteneurs bruts, des conteneurs dans une structure d’orchestration ou des nœuds de calcul dans un environnement en nuage, il existe une couche de gestion qui expose les informations de santé et accepte les commandes permettant de mettre à l’échelle et de réagir aux événements.

Le nombre de pièces en jeu augmente la probabilité statistique d’échec. Tous les autres facteurs étant égaux par ailleurs, cela nécessiterait davantage d’intervention humaine pour répondre à ces problèmes et les atténuer. Le système de surveillance étant responsable de l’identification des défaillances et de la dégradation du service, s’il peut se connecter aux interfaces de contrôle de la plate-forme, il peut atténuer une grande partie de ces problèmes. Une réponse immédiate et automatique déclenchée par le logiciel de surveillance peut aider à maintenir la santé opérationnelle de votre système.

Cette relation étroite entre le système de surveillance et la plate-forme de déploiement n’est pas nécessairement requise ou commune dans d’autres architectures. Cependant, les systèmes distribués automatisés se veulent autorégulateurs, avec la possibilité de faire évoluer et d’adapter en fonction de règles préconfigurées et du statut observé. Dans ce cas, le système de surveillance joue un rôle central dans le contrôle de l’environnement et dans la prise de décision.

Une autre raison pour laquelle le système de surveillance doit connaître la couche de provisioning est de traiter les effets secondaires des instances éphémères. Dans les environnements où il y a de nombreux rotations dans les instances de travail, le système de surveillance dépend des informations d’un canal latéral pour comprendre quand les actions étaient intentionnelles ou non. Par exemple, les systèmes capables de lire les événements d’API d’un approvisionneur peuvent réagir différemment lorsqu’un serveur est détruit intentionnellement par un opérateur et lorsqu’un serveur cesse de répondre soudainement sans événement associé. La possibilité de différencier ces événements peut aider votre surveillance à rester utile, précise et fiable, même si l’infrastructure sous-jacente peut changer fréquemment.

L’un des aspects les plus difficiles des charges de travail hautement distribuées est la compréhension de l’interaction entre différents composants et l’isolement des responsabilités lors d’une tentative d’analyse de la cause première. Puisqu’une seule demande peut toucher des dizaines de petits programmes pour générer une réponse, il peut être difficile d’interpréter d’où proviennent les goulots d’étranglement ou les changements de performances. Pour fournir de meilleures informations sur la manière dont chaque composant contribue à la latence et à la charge de traitement, une technique appelée traçage distribué est apparue.

Le traçage distribué est une approche des systèmes d’instrumentation qui consiste à ajouter du code à chaque composant pour éclairer le traitement de la demande lorsqu’il parcourt vos services. Chaque demande se voit attribuer un identifiant unique à la périphérie de votre infrastructure qui est transmis au fur et à mesure que la tâche traverse votre infrastructure. Chaque service utilise ensuite cet ID pour signaler les erreurs et les horodatages pour le moment où il a vu la demande pour la première fois et quand il l’a transmise à l’étape suivante. En agrégeant les rapports des composants à l’aide de l’ID de demande, vous pouvez suivre un chemin détaillé contenant des données de minutage précises dans votre infrastructure.

Cette méthode peut être utilisée pour comprendre combien de temps est consacré à chaque partie d’un processus et identifier clairement toute augmentation sérieuse de la latence. Cette instrumentation supplémentaire permet d’adapter la collecte de mesures à un grand nombre de composants de traitement. Lorsqu’il est mappé visuellement avec le temps sur l’axe des x, l’affichage résultant montre la relation entre les différentes étapes, la durée d’exécution de chaque processus et la relation de dépendance entre les événements devant s’exécuter en parallèle. Cela peut être incroyablement utile pour comprendre comment améliorer vos systèmes et comment vous utilisez votre temps.

La première étape pour vous assurer que vous pouvez répondre aux problèmes de vos systèmes consiste à savoir quand ils se produisent. Dans notre guide sur collecter des métriques à partir de votre infrastructure et de vos applications, nous avons présenté les quatre indicateurs de surveillance des signaux d’or identifié par l’équipe Google SRE comme le plus important à suivre. Les quatre signaux sont:

Ce sont toujours les meilleurs endroits pour commencer à instrumenter vos systèmes, mais le nombre de couches à surveiller augmente généralement pour les systèmes très distribués. L’infrastructure sous-jacente, le plan d’orchestration et la couche de travail nécessitent chacun une surveillance robuste avec des alertes réfléchies définies pour identifier les modifications importantes. Les conditions d’alerte peuvent devenir de plus en plus complexes pour tenir compte des éléments éphémères inhérents à la plate-forme.

Une fois que vos systèmes ont identifié une anomalie et notifié votre personnel, votre équipe doit commencer à collecter des données. Avant de poursuivre, ils doivent savoir quels composants sont affectés, quand l’incident a commencé et quelles conditions d’alerte spécifiques ont été déclenchées.

Le moyen le plus utile de commencer à comprendre la portée d’un incident est de commencer à un niveau élevé. Commencez votre enquête en consultant des tableaux de bord et des visualisations qui rassemblent et généralisent les informations provenant de vos systèmes. Cela peut vous aider à identifier rapidement les facteurs corrélés et à comprendre l’impact immédiat sur les utilisateurs. Au cours de ce processus, vous devriez pouvoir superposer des informations provenant de différents composants et hôtes.

Le but de cette étape est de commencer à créer un inventaire mental ou physique des objets à vérifier de manière plus détaillée et à commencer à hiérarchiser votre enquête. Si vous pouvez identifier une chaîne de problèmes liés qui traversent différentes couches, la couche la plus basse doit prévaloir: les corrections apportées aux couches fondamentales résolvent souvent les symptômes à des niveaux plus élevés. La liste des systèmes affectés peut servir de liste de contrôle informelle des emplacements sur lesquels valider les correctifs par la suite, lorsque le système d’atténuation est déployé.

Une fois que vous estimez que vous avez une vue de haut niveau raisonnable de l’incident, accédez au détail des composants et des systèmes de votre liste par ordre de priorité. Des métriques détaillées sur les unités individuelles vous aideront à tracer la voie de l’échec vers la ressource responsable la plus faible. Tout en examinant des tableaux de bord et des entrées de journal plus détaillés, référencez la liste des composants affectés pour essayer de mieux comprendre comment les effets secondaires se propagent dans le système. Avec les microservices, le nombre de composants interdépendants signifie que les problèmes se répercutent plus fréquemment sur d’autres services.

Cette étape consiste à isoler le service, le composant ou le système responsable de l’incident initial et à identifier le problème spécifique qui se produit. Il peut s’agir d’un code récemment déployé, d’une infrastructure physique défaillante, d’une erreur ou d’un bogue de la couche d’orchestration ou d’une modification de la charge de travail que le système n’a pas pu gérer correctement. Diagnostiquer ce qui se passe et pourquoi vous permet de découvrir comment atténuer le problème et retrouver la santé opérationnelle. Comprendre à quel point la résolution de ce problème pourrait résoudre les problèmes signalés sur d’autres systèmes peut vous aider à continuer à hiérarchiser les tâches d’atténuation.

Une fois les détails identifiés, vous pouvez travailler à la résolution ou à la résolution du problème. Dans de nombreux cas, il peut exister un moyen évident et rapide de restaurer le service en fournissant plus de ressources, en rétrogradant ou en redirigeant le trafic vers une autre implémentation. Dans ces scénarios, la résolution sera divisée en trois phases:

Dans de nombreux systèmes distribués, la redondance et les composants hautement disponibles garantissent la restauration rapide du service, mais des travaux supplémentaires peuvent être nécessaires en arrière-plan pour restaurer la redondance ou faire sortir le système d’un état dégradé. Vous devez utiliser la liste des composants concernés précédemment compilée en tant qu’indicateur pour déterminer si vos mesures d’atténuation initiales résolvent les problèmes de service en cascade. À mesure que la sophistication des systèmes de surveillance évolue, il peut également être en mesure d’automatiser certains de ces processus de récupération plus complets en envoyant des commandes à la couche de provisionnement afin d’afficher de nouvelles instances d’unités défaillantes ou de supprimer les unités défectueuses.

Compte tenu de l’automatisation possible au cours des deux premières phases, le travail le plus important pour l’équipe des opérations consiste souvent à comprendre les causes profondes d’un événement. Les connaissances acquises grâce à ce processus peuvent être utilisées pour développer de nouveaux déclencheurs et politiques permettant de prédire de futurs événements et d’automatiser davantage les réactions du système. Le logiciel de surveillance acquiert souvent de nouvelles fonctionnalités en réponse à chaque incident pour se prémunir contre les scénarios de défaillance récemment découverts. Pour les systèmes distribués, les traces distribuées, les entrées de journal, les visualisations de séries chronologiques et les événements tels que les déploiements récents peuvent vous aider à reconstruire la séquence d’événements et à identifier les domaines dans lesquels des processus humains et logiciels pourraient être améliorés.

En raison de la complexité particulière inhérente aux grands systèmes distribués, il est important de considérer le processus de résolution de tout événement important comme une opportunité d’apprendre et d’ajuster vos systèmes. Le nombre de composants distincts et de chemins de communication impliqués oblige à recourir de manière intensive à l’automatisation et à des outils facilitant la gestion de la complexité. Le codage de nouvelles leçons dans les mécanismes de réponse et les ensembles de règles de ces composants (ainsi que les règles opérationnelles suivies par votre équipe) est le meilleur moyen pour votre système de suivi de contrôler l’empreinte de gestion de votre équipe.