Traçage distribué : passé, présent et futur

Le traçage distribué est un sujet qui divise. Autrefois le doyen de chaque KubeCon , la technologie devait révolutionner l'observabilité.

Avance rapide de 5 ans, le battage médiatique s'est quelque peu calmé, on parle beaucoup plus de la douleur et l'adoption est modérée. Pendant ce temps, il continue d'y avoir une activité constante autour de l'expansion et de la standardisation de la technologie - Open Telemetry (basé sur OpenTracing) est le 2ème plus grand projet CNCF après Kubernetes. Alors, quel est le problème avec Distributed Tracing ? Doit-on l'appliquer tout de suite ou attendre et observer ?

Dans cet article, explorons en profondeur le traçage distribué

1. Quelle est la particularité du Distributed Tracing et pourquoi en avons-nous besoin ?
2. Quels sont les problèmes du traçage distribué aujourd'hui ?
3. Quels sont les développements à venir et comment relèvent-ils les défis existants ?

Introduction - Fonctionnement du traçage distribué

Pour les non-initiés, Distributed Tracing est une technologie qui nous permet de suivre une seule requête lorsqu'elle traverse plusieurs composants/microservices différents d'un environnement distribué. Chaque appel réseau effectué dans le chemin de la demande est capturé et représenté sous la forme d'une étendue.

Pour ce faire, les outils de traçage distribués insèrent un contexte de traçage unique (ID de traçage) dans l'en-tête de chaque demande et implémentent des mécanismes pour garantir que le contexte de traçage est propagé tout au long du chemin de la demande.

Comment une trace distribuée représente un chemin de requête

Pourquoi nous avons besoin du traçage distribué en premier lieu

Le traçage distribué est unique car il se concentre sur une demande en tant qu'unité d'observabilité. Dans une plate-forme de surveillance/métrique, un composant (par exemple, un service, un hôte) est l'unité fondamentale qui est observée. On peut poser à ces plateformes des questions sur le comportement de cette unité dans son ensemble, dans le temps. Par exemple, quel est l'état de santé/le débit/le taux d'erreur de ce service sur une période donnée ?

Avec les journaux, l'unité fondamentale observée est un événement - par exemple, chaque fois qu'un événement se produit pendant l'exécution du code, affiche des informations. Ces "événements" sont définis subjectivement par les développeurs lors de l'écriture du code. Le défi avec les journaux est qu'ils sont tous disjoints, chaque composant imprimant sa propre forme de messages de journal de manière isolée, sans moyen facile de les connecter ensemble pour avoir un sens.

En revanche, avec le traçage distribué, on observe une requête unique car elle traverse plusieurs composants. Cela nous permet de poser des questions sur le système distribué dans son ensemble et de comprendre ce qui s'est passé où dans un système complexe et interconnecté.

Le cas de base du traçage distribué repose sur l'argument selon lequel cette orientation autour des requêtes est la plus proche de l' expérience de l'utilisateur final . Et par conséquent, c'est aussi le plus intuitif pour la façon dont nous aimerions examiner et dépanner les architectures distribuées.

L'évolution du traçage distribué

Le traçage distribué a gagné en importance en raison de l'adoption généralisée d'architectures logicielles distribuées au cours de la dernière décennie.

L'architecture moderne basée sur les microservices est une évolution de l'histoire de la croissance d'Internet à la fin des années 90, lorsqu'il est devenu courant d'utiliser des systèmes de requête-réponse .

"Avec la fin des années 90 et la croissance explosive d'Internet, est venue l'énorme prolifération des systèmes de requête-réponse , tels que les sites Web à deux niveaux, avec un frontend de serveur Web et un backend de base de données... Les requêtes étaient une nouvelle dimension pour raisonner sur les systèmes , orthogonal à n'importe quelle machine ou processus dans l'ensemble."

- Traçage distribué en pratique, O'Reilly Media

Dans ces architectures de microservices, chaque requête finit par toucher plusieurs (10 ou même 100 de microservices), effectuant plusieurs appels réseau entre les deux. Reportez-vous ci-dessous pour l'architecture de microservices d'Uber, qui compte plus de 3000 services.

Architecture de microservices d'Uber de 2018. Source : https://www.uber.com/en-IN/blog/microservice-architecture/

Dans des systèmes aussi complexes, le traçage distribué devient essentiel pour toute forme de dépannage. En conséquence, Distributed Tracing a été lancé par de grandes entreprises qui ont été les premières à l'adopter en utilisant de grands environnements distribués complexes.

• L'article Dapper de Google publié en 2010 a marqué le début du traçage distribué

  
  

• Au cours des années suivantes, deux autres entreprises ont ouvert leurs propres systèmes de traçage distribués (Twitter open source Zipkin en 2012 et Uber open source Jaeger en 2017). Zipkin et Jaeger continuent d'être parmi les outils de traçage distribués les plus populaires, même aujourd'hui

  
  

• Depuis 2016, des efforts considérables ont été déployés pour normaliser le traçage distribué entre les composants via le projet OpenTracing. OpenTracing est finalement devenu OpenTelemetry en 2019. OpenTelemetry est très populaire et compte des milliers de contributeurs dans le monde.

  
  

• Désormais, le traçage distribué est largement considéré comme le troisième "pilier" de l'observabilité aux côtés des métriques et des journaux. La plupart des principaux acteurs de la surveillance et de l'observabilité proposent des outils de traçage distribués dans le cadre de leurs produits.

État du traçage distribué : théorie vs réalité

Cependant, malgré la promesse, l'enthousiasme et les efforts de la communauté, l'adoption du traçage distribué est aujourd'hui d'environ 25 %. Il n'est pas rare de trouver des entreprises sur des architectures de microservices qui se contentent de logs et de métriques, même si elles ont clairement besoin de traçage distribué.

Dans le même temps, les erreurs de production en temps moyen de résolution augmentent dans le monde aujourd'hui. 73 % des entreprises déclarent qu'il faut plus d'une heure pour résoudre les problèmes de production aujourd'hui.

Demandez à n'importe quel développeur quels sont les moments les plus douloureux de sa vie et il vous parlera du temps passé à déboguer une erreur Sev-1 en production avec ce qui semblait être quelques centaines de personnes à bout de souffle.

Il semble donc que toute entreprise soucieuse de son MTTR (c'est-à-dire presque toutes les entreprises) devrait utiliser le traçage distribué, et l'adoption aurait dû monter en flèche dans cet environnement. Mais les chiffres réels ne supportent pas cela - alors qu'est-ce qui donne ?

Les défis du traçage distribué aujourd'hui

Il existe aujourd'hui plusieurs problèmes avec le traçage distribué que les entreprises doivent surmonter pour obtenir de la valeur - qui ne sont pas tous discutés aussi largement dans le récit grand public.

1. La mise en œuvre est difficile !

Pour implémenter le traçage distribué dans un service aujourd'hui, nous devons apporter une modification au code et une version. Bien que la modification du code soit une demande assez courante d'observabilité, le défi spécifique au traçage distribué est le suivant : chaque service ou composant doit être instrumenté pour obtenir une trace distribuée, ou les ruptures de trace.

On ne peut pas simplement démarrer avec un seul service - comme on peut le faire avec la surveillance ou la journalisation - et réaliser de la valeur. Le traçage distribué nécessite une instrumentation sur un ensemble collectif de services pour générer des traces utilisables.

Cela nécessite une coordination entre plusieurs équipes et propriétaires de services pour apporter des modifications à leurs services. Cela devient donc un problème d'organisation - imaginez que des centaines d'équipes instrumentent leurs services sur plusieurs mois avant de pouvoir réaliser de la valeur.

C'est le plus grand défi du traçage distribué aujourd'hui.

2. Nécessité de décisions d'échantillonnage complexes

Ensuite, le volume de données de trace générées par Distributed Tracing peut être écrasant. Imaginez des centaines de services émettant chacun une petite quantité de données de suivi pour chaque requête . Cela représentera des millions de requêtes par seconde et rend le traçage distribué coûteux à la fois en termes de stockage et de bande passante réseau.

Bien que la journalisation fasse également la même chose (et émette plus de données par requête, qui sont ensuite gérées par des outils d'agrégation massive de journaux), la différence est que la plupart des entreprises disposent déjà aujourd'hui d'une journalisation. L'introduction d'un type de données supplémentaire qui sera presque aussi volumineux que la journalisation est une tâche ardue et doublera probablement les dépenses.

Pour gérer ce problème de coût, tous les systèmes de traçage distribués utilisent aujourd'hui l'échantillonnage et n'enregistrent qu'un sous-ensemble de traces. Les taux d'échantillonnage courants en pratique aujourd'hui se situent entre 0,1 % et 2 %. Le raisonnement est que même 1 % des échantillons sont suffisants pour donner une image globale décente de l'endroit où se trouvent les goulots d'étranglement des performances.

La plupart des plateformes permettent aujourd'hui aux clients de choisir leur stratégie d'échantillonnage et de faire leurs propres compromis coût-visibilité. Cependant, ce processus de décision s'ajoute à la surcharge déjà complexe d'instrumentation et de gestion d'un système de traçage distribué.

3. Mais l'échantillonnage diminue significativement la valeur

Supposons qu'une entreprise s'efforce d'instrumenter chaque service/composant, puis décide de la stratégie d'échantillonnage pour s'assurer qu'elle ne se ruine pas.

Et maintenant - devrions-nous nous attendre à ce que le MTTR chute de façon spectaculaire ? Non, car les développeurs ne peuvent pas utiliser le traçage distribué pour résoudre les problèmes, à cause de l'échantillonnage.

Imaginez l'expérience d'un développeur - "Je ne trouve pas le problème que je connais . J'ai généré l'erreur, mais je ne trouve pas la trace correspondante".

Alors que se passe-t-il ? Les développeurs cessent de faire confiance à la qualité des données de traçage distribuées et reviennent à leurs méthodes habituelles de débogage/dépannage (c'est-à-dire, à l'aide de journaux)

4. L'utilisation des développeurs est peu fréquente

Compte tenu de ces contraintes, le traçage distribué est aujourd'hui principalement vendu comme un moyen de résoudre les problèmes de performances .

N'oubliez pas qu'une trace distribuée de base nous indique simplement qui a appelé qui et combien de temps a pris chaque durée. Les traces distribuées ne nous disent pas ce qui s'est passé au sein du service qui a causé l'erreur/la latence élevée. Pour cela, les développeurs doivent toujours consulter le message du journal et/ou reproduire le problème localement pour déboguer.

Dans une entreprise type, les problèmes de performances représentent probablement moins de 10 % du total. Donc, en réalité, le traçage distribué n'est utile que pour ce petit segment de problèmes.

Le développeur moyen qui livre et possède un service utilise un outil de traçage distribué peut-être 2 à 3 fois par an.

Impact de tous ces défis

En résumé:

1. Le traçage distribué est difficile à mettre en œuvre
2. Le traçage distribué nécessite un échantillonnage étendu pour contrôler les coûts
3. Mais l'échantillonnage réduit considérablement la valeur
4. Par conséquent, les développeurs n'utilisent le traçage que pour le cas d'utilisation de performance unique et impair

Tout cela rend le cas RoI pour le traçage distribué assez flou.

Dans un cycle de battage médiatique typique, ce que nous pouvons dire, c'est que nous avons maintenant dépassé le stade des attentes exagérées et que la désillusion commence à s'installer.

Si nous pensons en termes d'état final, si l'avenir des systèmes informatiques est distribué, alors le traçage distribué est naturellement le vecteur le plus fondamental pour l'observabilité. Dans ce monde, toute entreprise dotée d'une architecture distribuée utilise le traçage comme principal mécanisme de dépannage de tout ce qui se produit en production - une véritable "observabilité" - par rapport à la surveillance passive des systèmes que nous avons aujourd'hui.

Avant de pouvoir arriver à cet état final, nous aurons besoin de plusieurs améliorations par rapport au statu quo. La bonne nouvelle est qu'une grande partie de cela est déjà en cours. Regardons chacun d'eux. Alors, que pouvons-nous nous attendre à voir dans le futur ?

L'avenir du traçage distribué

Instrumentation instantanée sans changement de code

Imaginez que vous déposiez un agent et que vous puissiez couvrir l'intégralité d'un système distribué (tous les services, composants) en une seule fois sans modification du code.

Cela semble raisonnablement possible dans les 2-3 prochaines années.

Les bibliothèques d'auto-instrumentation d'OpenTelemetry permettent déjà cela pour certains langages de programmation (cependant, elles sont insuffisantes dans les langages compilés tels que Go). En parallèle, des technologies comme eBPF évoluent pour permettre une instrumentation à l'échelle du système sans changement de code . Entre les deux, on peut s'attendre à ce que le problème d'instrumentation soit résolu en quelques années.

L'échantillonnage cède la place à une sélection basée sur l'IA des demandes d'intérêt

Dans un monde LLM, l'échantillonnage aléatoire commence à ressembler à une relique de l'âge des ténèbres. Idéalement, nous devrions pouvoir examiner 100 % des traces, identifier tout ce qui semble anormal et le stocker pour un examen futur. Plus d'échantillonnage aléatoire.

Si nous y réfléchissons, nous ne nous soucions pas vraiment des ~95 % de "demandes heureuses". Nous ne nous soucions que des ~ 5 % de traces anormales - erreurs, exceptions, latence élevée ou une forme d'erreurs logicielles. Nous avons donc juste besoin d'un moyen de regarder 100% et de choisir les 5% intéressants.

Il existe des mécanismes comme l'échantillonnage basé sur la queue qui visent à le faire aujourd'hui. Dans l'échantillonnage basé sur la queue, le système attend que toutes les plages d'une demande soient terminées, puis, en fonction de la trace complète, décide si elle doit être conservée.

Le principal défi avec l'échantillonnage basé sur la queue est que vous devez stocker toutes les étendues d'une trace jusqu'à ce que toute la demande soit terminée, puis décider de conserver ou de supprimer la trace. Cela signifie que nous stockons chaque demande, avec toutes les étendues, pendant une certaine période (jusqu'à ce que la demande soit terminée) - cela nécessite une architecture de données distincte avec des composants pour l'équilibrage de charge, le stockage et le traitement, ce qui est très complexe et coûteux.

OpenTelemetry a un collecteur d'échantillonnage basé sur la queue , cependant, il n'est pas encore mature et présente plusieurs défis d'évolutivité (en raison du problème mentionné ci-dessus). Pendant ce temps, plusieurs entreprises, dont ZeroK.ai , travaillent sur l'utilisation de l'IA pour rendre la détection des anomalies efficace et évolutive.

Avec le rythme rapide du développement dans cet espace, nous pouvons raisonnablement nous attendre à ce que ce problème soit également résolu dans les 3 à 5 prochaines années.

L'émergence de traces distribuées "riches" qui permettent tous les débogages

Un véritable saut dans la prochaine génération de traçage sera lorsque le traçage évoluera du domaine des "problèmes de performances uniquement" à "tous les problèmes". C'est alors que la véritable puissance du traçage distribué est libérée.

Pour que cela soit possible, chaque trace doit avoir un contexte riche.

Imaginez un scénario où chaque étendue dans chaque trace a :

• Charges utiles de requête et de réponse (avec masquage PII)

• Traces de pile pour toutes les exceptions

• Journaux

• Événements Kubernetes

• États du pod

• Et tout ce qui s'est produit le long de cette période

  
  

Tout en un flux intégré et transparent.

Et imaginez si la trace recherchée est super facile à trouver - il n'y a pas de lacunes dans les données liées à l'échantillonnage, les problèmes sont dédupliqués et regroupés, et peuvent être filtrés sur plusieurs dimensions.

C'est donc tout ce dont un développeur a besoin pour déboguer tout problème logiciel. Et potentiellement, tout ce dont un modèle d'IA a besoin pour diagnostiquer et indiquer à un développeur ce qui ne va pas.

Dans ce monde, la trace devient l'axe principal de l'observabilité, remplaçant la journalisation . Voilà à quoi pourrait ressembler l'état final du traçage distribué - bien qu'il ne soit pas encore là, il est visible d'où nous sommes aujourd'hui.

Le principal obstacle à cela est l'explosion du volume de données que le stockage de toutes ces données contextuelles entraînera. Nous aurons besoin d'innovations profondes dans les architectures de traitement et de stockage des données pour rendre cela possible. Il est encore tôt et nous devons attendre et voir ce qui se passe ici.

Résumé

En résumé, Distributed Tracing est une vue nécessaire et intuitive requise pour pouvoir observer les architectures d'applications distribuées en production.

La première génération de traçage distribué, bien que prometteuse, a été confrontée à plusieurs défis qui ont rendu difficile pour les entreprises de tirer parti du traçage, ce qui a quelque peu freiné l'adoption.

Cependant, plusieurs développements passionnants se produisent dans l'espace qui devraient rendre le traçage plus facile, plus simple et plus puissant que ce que nous avons aujourd'hui, rendant l'observabilité plus transparente à l'avenir.