Noter. trad.: L'auteur de ce document est Cindy Sridharan, ingénieure chez imgix spécialisée dans le développement d'API et, en particulier, les tests de microservices. Dans cet article, elle partage sa vision détaillée des problèmes actuels dans le domaine du traçage distribué, où, à son avis, il manque des outils véritablement efficaces pour résoudre les problèmes urgents.
[Illustration tirée de à propos du traçage distribué.]
On croit que difficile à mettre en œuvre, et le retour sur investissement . Il existe de nombreuses raisons pour lesquelles le traçage est problématique, citant souvent le travail nécessaire à la configuration de chaque composant du système pour transmettre les en-têtes appropriés à chaque requête. Même si ce problème existe, il n’est en aucun cas insurmontable. D’ailleurs, cela n’explique pas pourquoi les développeurs n’aiment pas vraiment le traçage (même s’il fonctionne déjà).
Le principal défi du traçage distribué n’est pas de collecter des données, de standardiser les formats de distribution et de présentation des résultats, ou de déterminer quand, où et comment échantillonner. je n'essaye pas d'imaginer banal ces "problèmes d'intelligibilité" sont en fait assez importants d'un point de vue technique et (si l'on considère vraiment l'Open Source) ) les défis politiques qui doivent être surmontés pour que ces problèmes soient considérés comme résolus.
Cependant, si l’on imagine que tous ces problèmes sont résolus, il y a de fortes chances que rien ne change de manière significative en termes de expérience utilisateur final. Le traçage peut ne pas être d’une utilité pratique dans les scénarios de débogage les plus courants, même après son déploiement.
Une trace si différente
Le traçage distribué comprend plusieurs composants disparates :
- équiper les applications et les middlewares d'outils de contrôle ;
- transfert de contexte distribué ;
- collecte de traces;
- stockage de traces ;
- leur extraction et leur visualisation.
On parle beaucoup du traçage distribué comme d'une sorte d'opération unaire dont le seul but est d'aider à diagnostiquer complètement le système. Cela est dû en grande partie à la façon dont les idées sur le traçage distribué se sont formées historiquement. DANS , réalisé lors de l'ouverture des sources Zipkin, il a été mentionné que ça [Zipkin] rend Twitter plus rapide. Les premières offres commerciales de traçage ont également été promues comme .
Noter. trad.: Pour rendre le texte plus facile à comprendre, définissons deux termes de base selon :
- Envergure — l'élément de base du traçage distribué. Il s'agit d'une description d'un certain flux de travail (par exemple, une requête de base de données) avec un nom, des heures de début et de fin, des balises, des journaux et un contexte.
- Les étendues contiennent généralement des liens vers d'autres étendues, ce qui permet de combiner plusieurs étendues en Tracer — visualisation de la vie d'une requête au fur et à mesure de son évolution dans un système distribué.
Les traces contiennent des données incroyablement précieuses qui peuvent faciliter des tâches telles que les tests de production, les tests de reprise après sinistre, les tests d'injection d'erreurs, etc. En fait, certaines entreprises utilisent déjà le traçage à des fins similaires. Commençons par a d'autres utilisations que le simple déplacement de travées vers le système de stockage :
- Par exemple, Uber traçage des résultats pour différencier le trafic de test et le trafic de production.
- Facebook tracez les données pour l'analyse du chemin critique et pour la commutation du trafic lors des tests réguliers de reprise après sinistre.
- Aussi réseau social Notebooks Jupyter qui permettent aux développeurs d'exécuter des requêtes arbitraires sur les résultats de trace.
- Adhérents (Injection d'échec basée sur la lignée) traces distribuées pour les tests avec injection d'erreurs.
Aucune des options répertoriées ci-dessus ne s'applique entièrement au scénario déboguer, au cours de laquelle l'ingénieur tente de résoudre le problème en regardant la trace.
Quand ça vient encore atteint le script de débogage, l'interface principale reste le diagramme vue de trace (même si certains l'appellent aussi "Diagramme de Gantt" ou "schéma cascade"). Sous vue de trace я toutes les étendues et les métadonnées qui les accompagnent qui constituent ensemble la trace. Chaque système de traçage open source, ainsi que chaque solution de traçage commerciale, offre un vue de trace interface utilisateur pour visualiser, détailler et filtrer les traces.
Le problème avec tous les systèmes de traçage que j'ai vus jusqu'à présent est que le résultat visualisation (traceview) reflète presque complètement les caractéristiques du processus de génération de traces. Même lorsque des visualisations alternatives sont proposées : cartes thermiques, topologies de services, histogrammes de latence, elles se résument finalement à vue de trace.
Dans le passé, je que la plupart des « innovations » en matière de traçage UI/UX semblent se limiter à métadonnées supplémentaires dans la trace, en y investissant des informations à cardinalité élevée (haute cardinalité) ou en offrant la possibilité d'explorer des étendues spécifiques ou d'exécuter des requêtes inter- et intra-traces. Dans ce cas, vue de trace reste le principal outil de visualisation. Tant que cet état de choses persiste, le traçage distribué occupera (au mieux) la 4ème place en tant qu'outil de débogage, après les métriques, les journaux et les traces de pile, et au pire, cela s'avérera être une perte de temps et d'argent.
Problème avec traceview
But vue de trace — fournir une image complète du mouvement d'une requête unique dans tous les composants du système distribué auquel elle est liée. Certains systèmes de traçage plus avancés vous permettent d'explorer des étendues individuelles et d'afficher une répartition au fil du temps. à l'intérieur un processus (lorsque les travées ont des limites fonctionnelles).
Le principe de base de l’architecture des microservices est l’idée selon laquelle la structure organisationnelle évolue avec les besoins de l’entreprise. Les partisans des microservices soutiennent que la répartition de diverses tâches commerciales en services individuels permet à de petites équipes de développement autonomes de contrôler l'intégralité du cycle de vie de ces services, leur donnant ainsi la possibilité de créer, tester et déployer ces services de manière indépendante. Cependant, l’inconvénient de cette distribution est la perte d’informations sur la manière dont chaque service interagit avec les autres. Dans de telles conditions, le traçage distribué se présente comme un outil indispensable pour déboguer interactions complexes entre les services.
Si tu es vraiment , alors pas une seule personne n'est capable de le garder dans sa tête полную image. En fait, développer un outil basé sur l’hypothèse que cela est même possible est en quelque sorte un anti-modèle (une approche inefficace et improductive). Idéalement, le débogage nécessite un outil qui aide affinez votre zone de recherche, afin que les ingénieurs puissent se concentrer sur un sous-ensemble de dimensions (services/utilisateurs/hôtes, etc.) pertinentes pour le scénario de problème considéré. Lorsqu'ils déterminent la cause d'une panne, les ingénieurs ne sont pas tenus de comprendre ce qui s'est passé pendant tous les services à la fois, puisqu'une telle exigence contredirait l'idée même d'architecture de microservices.
Cependant, traceview est exactement Ce. Oui, certains systèmes de traçage proposent des vues de trace compressées lorsque le nombre d'étendues dans la trace est si grand qu'elles ne peuvent pas être affichées dans une seule visualisation. Cependant, en raison de la grande quantité d'informations contenues, même dans une visualisation aussi simplifiée, les ingénieurs forcé « passez-le au crible », en limitant manuellement la sélection à un ensemble de services sources de problèmes. Malheureusement, dans ce domaine, les machines sont beaucoup plus rapides que les humains, moins sujettes aux erreurs et leurs résultats sont plus reproductibles.
Une autre raison pour laquelle je pense que traceview est erroné est qu'il n'est pas bon pour le débogage basé sur des hypothèses. À la base, le débogage est itératif un processus commençant par une hypothèse, suivi de la vérification de diverses observations et faits obtenus du système selon différents vecteurs, de conclusions/généralisations et d'une évaluation plus approfondie de la véracité de l'hypothèse.
Occasion rapide et pas cher tester des hypothèses et améliorer le modèle mental en conséquence est pierre angulaire débogage Tout outil de débogage doit être interactif et restreindre l'espace de recherche ou, en cas de fausse piste, permettre à l'utilisateur de revenir en arrière et de se concentrer sur une zone différente du système. L'outil parfait fera cela de manière proactive, attirant immédiatement l'attention de l'utilisateur sur les zones problématiques potentielles.
Hélas vue de trace ne peut pas être qualifié d’outil avec une interface interactive. Le mieux que vous puissiez espérer lors de son utilisation est de trouver une source d’augmentation de la latence et d’examiner toutes les balises et journaux possibles qui y sont associés. Cela n'aide pas l'ingénieur à identifier motifs dans le trafic, comme les spécificités de la distribution des retards, ou détecter des corrélations entre différentes mesures. peut aider à contourner certains de ces problèmes. Vraiment, analyse réussie utilisant l'apprentissage automatique pour identifier les étendues anormales et identifier un sous-ensemble de balises pouvant être associées à un comportement anormal. Cependant, je n'ai pas encore vu de visualisations convaincantes de résultats d'apprentissage automatique ou d'exploration de données appliqués à des étendues significativement différentes d'un traceview ou d'un DAG (graphe acyclique dirigé).
Les portées sont trop basses
Le problème fondamental avec traceview est que travées sont des primitives de trop bas niveau pour l'analyse de la latence et l'analyse des causes profondes. C'est comme analyser des commandes de processeur individuelles pour essayer de résoudre une exception, sachant qu'il existe des outils de niveau beaucoup plus élevé, comme le backtrace, avec lesquels il est beaucoup plus pratique de travailler.
Par ailleurs, je me permettrai d'affirmer ceci : idéalement, nous n'avons pas besoin image complète s'est produit pendant le cycle de vie de la demande, qui est représenté par des outils de traçage modernes. Au lieu de cela, une certaine forme d'abstraction de niveau supérieur est requise, contenant des informations sur ce que mal tourné (similaire à backtrace), avec un peu de contexte. Au lieu de regarder la trace en entier, je préfère la voir часть, où quelque chose d'intéressant ou d'inhabituel se produit. Actuellement, la recherche est effectuée manuellement : l'ingénieur reçoit la trace et analyse indépendamment les travées à la recherche de quelque chose d'intéressant. L'approche des personnes qui regardent les étendues dans les traces individuelles dans l'espoir de détecter une activité suspecte n'est pas du tout évolutive (surtout lorsqu'elles doivent donner un sens à toutes les métadonnées codées dans différentes étendues, telles que l'ID de l'étendue, le nom de la méthode RPC, la durée de l'étendue). 'a, journaux, balises, etc.).
Alternatives à TraceView
Les résultats des traces sont plus utiles lorsqu’ils peuvent être visualisés de manière à fournir un aperçu non trivial de ce qui se passe dans les parties interconnectées du système. En attendant, le processus de débogage reste en grande partie inerte et dépend de la capacité de l'utilisateur à remarquer les bonnes corrélations, à vérifier les bonnes parties du système ou à assembler les pièces du puzzle - par opposition à instrument, aidant l'utilisateur à formuler ces hypothèses.
Je ne suis ni un concepteur visuel ni un spécialiste de l'UX, mais dans la section suivante, je souhaite partager quelques idées sur ce à quoi pourraient ressembler ces visualisations.
Focus sur des services spécifiques
A l’heure où l’industrie se regroupe autour des idées , il semble raisonnable que les équipes individuelles devraient donner la priorité à l'alignement de leurs services sur ces objectifs. Il s'ensuit que orienté service la visualisation est la mieux adaptée à de telles équipes.
Les traces, surtout sans échantillonnage, sont un trésor d'informations sur chaque composant d'un système distribué. Ces informations peuvent être transmises à un processeur astucieux qui fournira aux utilisateurs orienté service Ils peuvent être identifiés à l'avance, avant même que l'utilisateur ne regarde les traces :
- Diagrammes de distribution de latence uniquement pour les requêtes très importantes (demandes aberrantes);
- Diagrammes de distribution des délais pour les cas où les objectifs du SLO du service ne sont pas atteints ;
- Les balises les plus « courantes », « intéressantes » et « bizarres » dans les requêtes qui sont le plus souvent se répètent;
- Répartition de la latence pour les cas où dépendances les services n'atteignent pas leurs objectifs SLO ;
- Répartition de la latence pour divers services en aval.
Certaines de ces questions ne trouvent tout simplement pas de réponse dans les mesures intégrées, ce qui oblige les utilisateurs à examiner attentivement les étendues. En conséquence, nous avons un mécanisme extrêmement hostile aux utilisateurs.
Cela soulève la question : qu’en est-il des interactions complexes entre divers services contrôlés par différentes équipes ? N'est-ce pas vue de trace n’est-il pas considéré comme l’outil le plus approprié pour mettre en évidence une telle situation ?
Les développeurs mobiles, les propriétaires de services sans état, les propriétaires de services gérés avec état (comme les bases de données) et les propriétaires de plateformes peuvent être intéressés par autre chose. présentation système distribué; vue de trace est une solution trop générique pour ces besoins fondamentalement différents. Même dans une architecture de microservices très complexe, les propriétaires de services n’ont pas besoin d’une connaissance approfondie de plus de deux ou trois services en amont et en aval. Essentiellement, dans la plupart des scénarios, les utilisateurs doivent uniquement répondre aux questions concernant ensemble limité de services.
C'est comme regarder un petit sous-ensemble de services à la loupe dans le seul but de l'examiner attentivement. Cela permettra à l'utilisateur de poser des questions plus urgentes concernant les interactions complexes entre ces services et leurs dépendances immédiates. Ceci est similaire au backtrace dans le monde des services, où l'ingénieur sait que faux, et a également une certaine compréhension de ce qui se passe dans les services environnants pour comprendre pourquoi.
L'approche que je préconise est exactement le contraire de l'approche descendante basée sur la vue de trace, dans laquelle l'analyse commence par la trace entière, puis se déroule progressivement jusqu'à des étendues individuelles. En revanche, une approche ascendante commence par analyser une petite zone proche de la cause potentielle de l’incident, puis étend l’espace de recherche si nécessaire (avec la possibilité de faire appel à d’autres équipes pour analyser une gamme plus large de services). La deuxième approche est mieux adaptée pour tester rapidement les hypothèses initiales. Une fois les résultats concrets obtenus, il sera possible de passer à une analyse plus ciblée et détaillée.
Construire une topologie
Les vues spécifiques au service peuvent être incroyablement utiles si l'utilisateur sait que un service ou un groupe de services est responsable de l'augmentation de la latence ou de la survenue d'erreurs. Cependant, dans un système complexe, l'identification du service incriminé peut s'avérer une tâche non triviale lors d'une panne, surtout si aucun message d'erreur n'a été signalé par les services.
La création d'une topologie de service peut être d'une grande aide pour déterminer quel service connaît un pic de taux d'erreur ou une augmentation de la latence qui entraîne une dégradation notable du service. Quand je parle de construire une topologie, je ne veux pas dire carte des services, affichant tous les services disponibles dans le système et connus pour leur . Cette vue n'est pas meilleure que traceview basée sur un graphe acyclique orienté. Au lieu de cela, j'aimerais voir topologie de service générée dynamiquement, sur la base de certains attributs tels que le taux d'erreur, le temps de réponse ou tout paramètre défini par l'utilisateur permettant de clarifier la situation avec des services suspects spécifiques.
Prenons un exemple. Imaginons un site d'information hypothétique. Service de page d'accueil (page de garde) échange des données avec Redis, avec un service de recommandation, avec un service de publicité et un service de vidéo. Le service vidéo prend des vidéos de S3 et des métadonnées de DynamoDB. Le service de recommandation reçoit les métadonnées de DynamoDB, charge les données de Redis et MySQL et écrit des messages dans Kafka. Le service de publicité reçoit des données de MySQL et écrit des messages dans Kafka.
Vous trouverez ci-dessous une représentation schématique de cette topologie (de nombreux programmes de routage commerciaux construisent la topologie). Cela peut être utile si vous avez besoin de comprendre les dépendances des services. Cependant, pendant déboguer, lorsqu'un certain service (par exemple un service vidéo) présente un temps de réponse accru, une telle topologie n'est pas très utile.
Schéma de service d'un site d'actualités hypothétique
Le schéma ci-dessous serait mieux adapté. Il y a un problème avec le service (Vidéo) représenté en plein centre. L'utilisateur le remarque immédiatement. De cette visualisation, il ressort clairement que le service vidéo fonctionne anormalement en raison d'une augmentation du temps de réponse S3, ce qui affecte la vitesse de chargement d'une partie de la page principale.
Topologie dynamique affichant uniquement les services « intéressants »
Les topologies générées dynamiquement peuvent être plus efficaces que les cartes de services statiques, en particulier dans les infrastructures élastiques et à mise à l'échelle automatique. La possibilité de comparer et de contraster les topologies de services permet à l'utilisateur de poser des questions plus pertinentes. Des questions plus précises sur le système sont plus susceptibles de conduire à une meilleure compréhension de son fonctionnement.
Affichage comparatif
Une autre visualisation utile serait un affichage comparatif. Actuellement, les traces ne sont pas très adaptées aux comparaisons côte à côte, les comparaisons sont donc généralement travées. Et l'idée principale de cet article est précisément que les étendues sont de trop bas niveau pour extraire les informations les plus précieuses des résultats de trace.
La comparaison de deux traces ne nécessite pas de visualisations fondamentalement nouvelles. En fait, quelque chose comme un histogramme représentant les mêmes informations qu'un traceview est suffisant. Étonnamment, même cette méthode simple peut apporter bien plus de fruits que la simple étude de deux traces séparément. La possibilité serait encore plus puissante visualiser comparaison des traces Au total. Il serait extrêmement utile de voir comment une modification de configuration de base de données récemment déployée pour activer le GC (garbage collection) affecte le temps de réponse d'un service en aval sur une échelle de plusieurs heures. Si ce que je décris ici ressemble à une analyse A/B de l'impact des changements d'infrastructure dans de nombreux services en utilisant les résultats des traces, alors vous n'êtes pas trop loin de la vérité.
Conclusion
Je ne remets pas en question l'utilité du traçage lui-même. Je crois sincèrement qu’il n’existe aucune autre méthode de collecte de données aussi riche, causale et contextuelle que celle contenue dans une trace. Cependant, je pense également que toutes les solutions de traçage utilisent ces données de manière extrêmement inefficace. Tant que les outils de traçage resteront bloqués sur la représentation traceview, ils seront limités dans leur capacité à tirer le meilleur parti des informations précieuses pouvant être extraites des données contenues dans les traces. De plus, il existe un risque de développement d'une interface visuelle totalement peu conviviale et peu intuitive qui limiterait considérablement la capacité de l'utilisateur à résoudre les erreurs dans l'application.
Le débogage de systèmes complexes, même avec les outils les plus récents, est incroyablement difficile. Les outils doivent aider le développeur à formuler et à tester une hypothèse, fournissant activement informations pertinentes, identifiant les valeurs aberrantes et notant les caractéristiques de la répartition des retards. Pour que le traçage devienne l'outil de choix des développeurs lors du dépannage des échecs de production ou de la résolution de problèmes couvrant plusieurs services, des interfaces utilisateur et des visualisations originales sont nécessaires, plus cohérentes avec le modèle mental des développeurs qui créent et exploitent ces services.
Il faudra un effort mental important pour concevoir un système qui représentera les différents signaux disponibles dans les résultats de trace d'une manière optimisée pour faciliter l'analyse et l'inférence. Vous devez réfléchir à la manière d'abstraire la topologie du système pendant le débogage de manière à aider l'utilisateur à surmonter les angles morts sans examiner les traces ou les étendues individuelles.
Nous avons besoin de bonnes capacités d’abstraction et de superposition (en particulier dans l’interface utilisateur). Ceux qui s’intégreraient bien dans un processus de débogage basé sur des hypothèses où vous pouvez poser des questions de manière itérative et tester des hypothèses. Ils ne résoudront pas automatiquement tous les problèmes d’observabilité, mais ils aideront les utilisateurs à aiguiser leur intuition et à formuler des questions plus intelligentes. J’appelle à une approche plus réfléchie et innovante de la visualisation. Il existe ici une réelle perspective d’élargir les horizons.
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «».
Source: habr.com