Le développement cloud natif a révolutionné le développement d’applications de manière à la fois positive et stimulante. L’adoption d’architectures de microservices sur des infrastructures basées sur des conteneurs permet des cycles de vie de développement de logiciels plus rapides. Dans le même temps, des problèmes peuvent survenir lorsque des modifications sont apportées aux applications, telles que l’ajout de nouvelles fonctionnalités. De plus, les mises à jour des applications peuvent se produire plusieurs fois par jour. Alors, comment les équipes détectent-elles les problèmes lorsque des messages d’erreur apparaissent ou lorsque le chargement d’une application prend soudainement plus de temps ?
Contrairement à l’approche monolithique du développement d’applications, où un simple appel d’application permet de trouver facilement où se trouve un problème, les applications cloud natives et l’infrastructure basée sur des conteneurs sur lesquelles elles s’exécutent sont éphémères. Cela signifie que les problèmes sont insaisissables. Le besoin de traçage distribué, qui vous indique exactement où un problème se produit, devient extrêmement important pour les équipes qui ont besoin de réparer rapidement leurs applications.
Que fait le traçage distribué ?
Le traçage distribué permet de voir où les choses se passent. De plus, le traçage distribué capture des unités de travail individuelles, également appelées étendues, dans un système distribué. Un bon exemple de traçage distribué est une demande de flux de travail, qui est une série d’activités nécessaires pour accomplir une tâche. Nous voyons en fait des demandes de flux de travail dans les activités quotidiennes… comme commander nos cupcakes préférés en ligne. Dans l’exemple ci-dessous, vous verrez comment cela fonctionne :
Disons que Nichelle et Robin veulent chacun savoir si des cupcakes de velours rouge sont en stock dans leur boulangerie locale. Nichelle et Robin allaient sur leurs téléphones portables respectifs, ouvraient l’application de la boulangerie et recherchaient « red velvet ».
- Lorsque Nichelle et Robin lancent leurs recherches de cupcakes de velours rouge, chacun déclenche une demande de flux de travail pour obtenir des informations sur l’inventaire
- Ces demandes de flux de travail sont ensuite traitées via des services d’application
- Les informations sont renvoyées à leurs applications mobiles respectives
Gardez à l’esprit que chaque demande de flux de travail pour Nichelle et Robin était la même – ils devaient chacun passer par leurs applications et utiliser les mêmes services et demander le même type de cupcake. Cependant, les métadonnées associées à chacun d’eux – comme les balises, les performances ou les descripteurs – peuvent être différentes. Alors que les demandes de workflow peuvent être les mêmes pour plusieurs utilisateurs, les métadonnées associées sont uniques.
Voir les métadonnées de trace est utile pour les ingénieurs qui enquêtent sur les problèmes, car cela leur permet d’identifier des modèles, des anomalies ou des valeurs aberrantes et aide à identifier où se situent les problèmes dans une pile.
Comment le traçage distribué est-il devenu ?
Dans un monde monolithique, les demandes de flux de travail étaient faciles à suivre malgré la complexité des composants de l’application, ce qui facilitait la localisation d’un problème. Cependant, dans le monde actuel des microservices natifs du cloud, les choses sont inversées. Les composants d’application sont plus simples, mais les workflows de demande sont plus complexes.
À mesure que ce changement de complexité se poursuit, la nécessité de comprendre où les problèmes se produisent est devenue plus difficile à discerner. Pour en revenir à notre métaphore de la boulangerie : si Nichelle et Robin veulent savoir combien de cupcakes de velours rouge sont en stock dans leur boulangerie locale, les demandes de flux de travail sont chacune différentes entre une configuration monolithique et une configuration de microservices.
Dans un monde monolithique, cela aurait été un simple flux de travail vers une application qui effectuerait ensuite plusieurs appels au sein de ce service pour collecter ces données. Mais si nous sommes dans un environnement de microservices et que nous répétons la même action de demande d’inventaire de notre magasin de cupcakes, l’interface utilisateur envoie simultanément un avis à plusieurs microservices et reçoit simultanément ces données de chaque microservice.
Bien que chaque demande de flux de travail puisse indiquer qu’il y a un problème, s’il en existe un, il est moins susceptible d’être intuitif où le problème vient de l’environnement des microservices.
Les premiers outils de traçage distribués étaient difficiles à utiliser
Le marché a répondu à ces changements architecturaux en construisant de nouveaux outils de traçage spécialisés, mais ces outils sont rarement utilisés. Pourquoi? La première vague d’outils de traçage était :
- Difficile à utiliser
- Adopté par des utilisateurs techniquement avancés – des utilisateurs qui ont généralement une compréhension approfondie de l’architecture et de l’outil
- N’a pas fourni le niveau de détail nécessaire pour découvrir facilement où un problème existe
Par exemple, l’échantillonnage – qui vous permet de décider quelles données afficher – est le bon outil pour certains, mais pas pour d’autres qui ont besoin de stocker moins de détails. L’essentiel est que la possibilité de définir les intervalles d’échantillonnage doit être laissée à l’utilisateur et non à l’outil de traçage distribué lui-même.
Le traçage distribué doit être facile pour les utilisateurs novices et experts
Reprenons notre exemple de boulangerie de Nichelle et Robin, qui souhaitaient connaître l’état des stocks de cupcakes red velvet. S’il y a un problème de recherche d’inventaire, les ingénieurs recevront probablement un message d’erreur et un administrateur recevra une alerte via leurs données métriques indiquant qu’il y a un problème. Si nous avions effectué ce même flux de travail de demande de manière monolithique – en instrumentant (ordonnant) à chaque unité de travail de renvoyer les données de télémétrie à notre outil d’observabilité – cela prendrait un temps, des ressources et des coûts précieux. Et si la transaction a déjà eu lieu au moment où nous avons identifié un problème, il devient beaucoup plus difficile de déterminer où le problème s’est produit.
Ajoutez à cela la complexité croissante de la collaboration à mesure que les équipes au sein des organisations s’agrandissent, l’ensemble du processus semble être plus orienté boîte noire plutôt qu’intuitif. S’assurer que le bon expert est affecté à un problème dès le début est crucial pour le succès de votre entreprise et garantit une expérience transparente pour les clients.
Comment le traçage distribué profite-t-il à mon organisation ?
Le traçage distribué adopte une approche à deux volets au profit de votre organisation.
- La première est que les métriques sont un système d’alerte précoce pour informer les équipes qu’il y a un problème. Cela permet également aux membres novices des équipes de comprendre plus rapidement ce qui se passe plutôt que d’avoir à faire appel à un utilisateur expérimenté en cas de problème.
- Deuxièmement, le traçage distribué fournit des informations sur les services qui permettent aux équipes de développement de connaître et de comprendre des éléments tels que la mauvaise santé du système ou d’identifier les goulots d’étranglement dans la pile logicielle. Tout cela se produit en conjonction avec la capacité d’alerte précoce décrite ci-dessus. Les équipes reçoivent les données dont elles ont besoin pour restaurer les services, offrir une expérience utilisateur positive et respecter les accords de niveau de service de l’organisation.
Pour en revenir à mon exemple précédent de Nichelle et Robin voulant savoir combien de cupcakes de velours rouge sont en stock : avec le traçage distribué, les équipes sont en mesure de savoir où dans ce flux de travail de demande il peut y avoir un problème.
Pourquoi ai-je besoin d’un traçage distribué ?
Suivi, c’est pourquoi. Sans suivi, nous ne pouvons pas dire où ou quand quelque chose s’est produit dans les flux de travail.
Mais comment cela s’applique-t-il aux équipes de développement ? Voici quelques-unes des principales raisons pour lesquelles la mise en œuvre du traçage distribué dans votre organisation peut vous aider, ainsi que vos clients. Traçage distribué :
- Informe les équipes de développement de la santé et de l’état des systèmes d’application déployés et des microservices
- Identifie les comportements irréguliers résultant de l’automatisation de la mise à l’échelle
- Examine comment les temps de réponse moyens, les fréquences d’erreur et d’autres mesures se reflètent dans l’expérience de l’utilisateur final
- Suit et enregistre des statistiques vitales sur les performances avec des tableaux de bord conviviaux
- Débogue et isole les goulots d’étranglement au sein du système tout en résolvant les problèmes de performances au niveau du code
- Reconnaît et traite la cause fondamentale des problèmes inattendus