Pratiques recommandées en traçage distribué

Best Practices in Distributed Tracing

La traçabilité distribuée est désormais un élément incontournable dans la pile de surveillance moderne. Avec le passage aux microservices, nous avions besoin d’une nouvelle façon d’observer comment nos services interagissent. La traçabilité distribuée offre cette vision en nous permettant de réaliser une traçabilité des requêtes – c’est-à-dire de suivre une requête à travers les composants de notre système distribué. Aujourd’hui, la traçabilité distribuée est utilisée pour identifier les goulots d’étranglement de performance, résoudre les problèmes de débogage et comprendre comment nos systèmes interagissent en production.

Cependant, la mise en œuvre de la traçabilité distribuée est complexe et la valeur que les équipes en tirent dépend largement de sa mise en œuvre. Les mécanismes de mise en œuvre tels que les composants instrumentés, le taux d’échantillonnage et la qualité de la visualisation des traces influencent tous la valeur que les entreprises tirent de la traçabilité, ce qui influence à son tour l’adoption par les développeurs. De plus, cet espace évolue continuellement, avec de nouveaux outils et techniques émergents tout le temps.

Dans cet article, examinons les meilleures pratiques pour la traçabilité distribuée en 2023.

Qu’est-ce que la traçabilité distribuée ?

La traçabilité distribuée fait référence à un mécanisme qui nous permet de suivre une seule requête lorsqu’elle traverse plusieurs services dans un environnement distribué.

• Régression linéaire à partir de zéro avec NumPy
• Les 5 meilleurs outils d’IA pour maximiser la productivité
• Utilisation de la ROC pour les dessins techniques complexes

Pourquoi avons-nous besoin de la traçabilité distribuée.

Pour permettre cela, les outils de traçabilité distribuée insèrent un contexte de trace unique (ID de trace) dans l’en-tête de chaque requête et mettent en œuvre des mécanismes pour garantir que ce contexte de trace est propagé tout au long du parcours de la requête.

Chaque appel réseau effectué dans le parcours de la requête est capturé et représenté sous la forme d’une spanne. Une spanne est une unité de base d’une trace – elle représente un événement unique au sein de la trace, et une trace peut avoir une ou plusieurs spannes. Une spanne est composée de messages de journal, de données liées au temps et d’autres attributs permettant de fournir des informations sur l’opération qu’elle suit.

Anatomie d’une trace distribuée.

Grâce à sa vision unique, la traçabilité distribuée ouvre plusieurs nouveaux cas d’utilisation/améliore les cas d’utilisation existants. Elle nous permet de comprendre les interdépendances des services (par exemple, qui appelle mon service), d’identifier les goulots d’étranglement de performance (quelle requête spécifique à la base de données dégrade ma latence ?), d’identifier rapidement les points de défaillance pour le débogage (quelle API provoque cette erreur 500 ?) et d’avoir des SLO plus granulaires.

Composants d’un système de traçabilité distribuée

Pour mettre en œuvre n’importe quel système de traçabilité distribuée, nous installons quatre composants distincts :

1. Bibliothèque d’instrumentation
2. Collecteur (préprocesseur)
3. Stockage en arrière-plan
4. Interface de visualisation

Aujourd’hui, plusieurs options sont disponibles pour chacun de ces composants – vous pouvez utiliser une seule plateforme qui fait les quatre ci-dessus, ou assembler votre propre framework de traçabilité distribuée en utilisant différentes solutions pour différents composants.

Composants d’un système de traçabilité.

Bibliothèque d’instrumentation

C’est la partie intégrée dans chaque application ou service. Lorsqu’une application s’exécute, la bibliothèque d’instrumentation veille à ce que les identifiants de trace soient ajoutés à chaque requête, ou que le contexte de trace (ID de trace) soit propagé dans la spanne suivante. La bibliothèque envoie ces données à un collecteur.

Collecteur

Le collecteur est un intermédiaire entre la bibliothèque d’instrumentation et le stockage en arrière-plan. Il rassemble les traces, les traite (par exemple, agréger les spannes, échantillonner) et les prépare pour le stockage.

Stockage en arrière-plan

Le stockage en arrière-plan persiste et indexe les données de trace. Il utilise généralement un système de stockage distribué capable de gérer de grands volumes de données et permet des requêtes et des récupérations efficaces.

Interface de visualisation

Il s’agit de l’interface utilisateur du système de traçabilité distribuée. Elle permet aux développeurs et aux opérateurs d’interagir avec les données de trace. Cette couche fournit des outils pour interroger, rechercher et filtrer les données de trace en fonction de divers critères. Elle présente les données de trace de manière visuellement significative, souvent sous la forme d’un graphe de trace ou d’une chronologie, ce qui permet aux utilisateurs d’analyser la séquence d’événements et d’identifier les goulots d’étranglement ou les problèmes.

La mise en œuvre des systèmes de traçabilité distribuée est complexe

Malgré plusieurs avantages, la mise en œuvre des systèmes de traçabilité distribuée (surtout de manière optimale) n’est pas encore une tâche facile à résoudre. Cela nécessite que l’équipe de mise en œuvre prenne plusieurs décisions, et ces décisions ont un impact significatif sur la valeur que le reste de l’équipe d’ingénierie tire de la traçabilité. Il n’est pas rare que les entreprises mettent en œuvre la traçabilité distribuée et paient un demi-million de dollars par an, pour que le développeur moyen ne l’utilise que deux fois par an. Voir ci-dessous quelques bonnes pratiques pour une mise en œuvre efficace de la traçabilité.

Meilleures pratiques pour la traçabilité distribuée

Choisissez OTel pour l’instrumentation

Il existe plusieurs frameworks de traçage open source populaires, tels que OpenTelemetry, Jaeger et Zipkin. Aujourd’hui, en 2023, OTel est devenu un choix évident pour les raisons suivantes:

• Couverture étendue: OTel dispose de bibliothèques et de SDK d’instrumentation pour différents langages de programmation et frameworks et dispose maintenant d’une large couverture. Consultez ici pour voir ce que OTel prend en charge.
• Neutralité vis-à-vis des vendeurs: À ce jour, la plupart des vendeurs prennent en charge l’instrumentation OTel. Vous pouvez donc instrumenter avec OTel et envoyer les données à n’importe quel vendeur de votre choix. Vous bénéficierez d’une interopérabilité et d’une portabilité des vendeurs dans le temps (si vous choisissez de changer de vendeur). Voici une liste de fournisseurs d’observabilité qui prennent en charge nativement les données OTel, et voici un registre de bibliothèques et de plugins pour connecter OTel à d’autres vendeurs.
• Maturité et stabilité: OTel a mûri pendant plusieurs années, bénéficiant d’un large soutien de la communauté. Il est maintenant le deuxième plus grand projet de l’écosystème CNCF en termes de contributeurs, juste après Kubernetes lui-même. La forte communauté assure qu’il continue d’évoluer et d’ajouter rapidement une prise en charge de nouvelles technologies.

Profitez de l’instrumentation automatique lorsque c’est possible

OpenTelemetry offre deux façons d’instrumenter le code dans les applications et les composants : l’instrumentation manuelle et l’instrumentation automatique. Si vous utilisez Kubernetes et que la plupart de vos services sont en Java, NodeJS ou Python, profitez de l’instrumentation automatique car elle réduit les efforts de mise en œuvre.

Instrumentation manuelle

Le code OTel doit être ajouté à l’application par le développeur, ce qui nécessite une modification du code. L’instrumentation manuelle permet une personnalisation plus poussée en termes de spans et de traces. La plupart des langages sont couverts pour l’instrumentation manuelle – C++, .NET, Go, Java, Python, etc. Consultez ici pour la dernière liste.

Instrumentation automatique

C’est une façon d’instrumenter des applications/services sans apporter de modifications au code ou sans avoir à recompiler l’application. Un agent intelligent est attaché à une application, lit son activité et extrait les traces. Cela est possible si vous êtes sur Kubernetes. Aujourd’hui, OTel prend en charge l’instrumentation automatique pour Java, NodeJS, Python, etc. (consultez ici pour la dernière liste). La personnalisation des spans et des traces est limitée avec l’instrumentation automatique (par rapport à l’instrumentation manuelle) mais est suffisante pour la plupart des cas d’utilisation.

Commencez par les chemins critiques et élargissez à partir de là

Il est impraticable d’instrumenter chaque service/composant dans de grands systèmes distribués en une seule fois, il est donc important de choisir judicieusement les chemins à instrumenter en premier et comment les élargir par la suite. Voici quelques directives/principes à suivre ici:

Commencez de l’extérieur vers l’intérieur / Commencez près des utilisateurs

Il est souvent préférable de commencer de l’extérieur et de progresser vers l’intérieur. Cela signifie commencer aux points où une demande entre dans votre application, les demandes entrantes des utilisateurs ou des clients externes. En commençant par les points d’entrée, il est plus facile d’obtenir une vision globale de la façon dont les demandes circulent dans le système.

Choisissez les chemins les plus critiques dans le système et instrumentez-les en premier

La ligne directrice générale est d’identifier les chemins de demande les plus importants de votre système ; ce sont peut-être ceux qui sont les plus fréquemment consultés ou qui ont le plus d’impact sur la surveillance globale des performances de l’application. Commencez par instrumenter ces chemins critiques en premier afin de pouvoir démontrer de la valeur à l’ensemble de l’organisation, puis élargissez à partir de là.

Instrumentez toujours les chemins de demande de bout en bout afin qu’une trace ne se rompe pas

Quels que soient les chemins que vous choisissez, assurez-vous que le chemin est instrumenté de bout en bout – ce qui signifie que chaque service et composant du chemin de demande est instrumenté pour propager le contexte (TraceID) et générer les spans nécessaires. Toute lacune entraîne des traces incomplètes ou rompues, ce qui annule les efforts investis pour instrumenter les services en amont.

Soyez intentionnel en matière d’échantillonnage

Dans 99% des cas, les entreprises souhaitent échantillonner leurs traces. Cela s’explique par le fait que si vous stockez chaque trace, vous pourriez stocker et gérer une quantité massive de données.

Prenons un exemple. Supposons que chaque span représente 500 octets (y compris les balises et les journaux). Si votre application traite 2000 demandes par seconde et dispose de 20 services différents, cela génère 20 Mo de données chaque seconde, soit 72 Go par heure, soit 1 To par jour, pour une configuration de 20 services simple.

C’est pourquoi la plupart des entreprises finissent par stocker un échantillon des traces distribuées. Il est important de sélectionner la bonne stratégie d’échantillonnage afin d’obtenir une visibilité sur ce qui vous intéresse tout en gardant le contrôle sur les coûts.

De manière générale, il existe deux catégories d’échantillonnage :

1. Échantillonnage en amont/ basé sur l’en-tête

C’est une façon simple de décider quelles traces conserver avant que des traces n’aient été générées pour une demande donnée. Cela s’appelle l’échantillonnage basé sur l’en-tête, car la décision est prise au début ou à la “tête” de la demande. Parfois, on parle d’échantillonnage non biaisé lorsque les décisions sont prises sans même regarder la demande. Dans l’échantillonnage basé sur l’en-tête, plusieurs mécanismes sont couramment utilisés, comme ci-dessous.

• Échantillonnage probabiliste ou à taux fixe : Sélection aléatoire d’un sous-ensemble de traces à conserver en fonction d’un taux d’échantillonnage fixe – disons 1%
• Échantillonnage avec limitation de taux : Fixation d’une limite fixe sur le nombre de demandes à tracer par unité de temps. Par exemple, si la limite de taux est fixée à 100 demandes par minute, seules les 100 premières demandes de cette minute seront tracées.
• Échantillonnage basé sur la priorité : L’échantillonnage basé sur la priorité attribue des priorités différentes aux demandes, et le taux d’échantillonnage est ajusté en conséquence. Les demandes prioritaires (par exemple, les transactions critiques) ont un taux d’échantillonnage plus élevé, tandis que les demandes de moindre priorité ont un taux plus faible.

2. Échantillonnage basé sur la fin

L’échantillonnage basé sur la fin est basé sur les réponses au sein de la trace, par exemple, la latence élevée et les erreurs. Cette méthode garantit que les demandes “intéressantes” sont tracées, même lorsque les taux d’échantillonnage globaux sont faibles. Cependant, l’échantillonnage basé sur la fin est beaucoup plus difficile à mettre en œuvre (par rapport à d’autres méthodes plus simples), car il faudrait stocker dans un tampon toutes les traces jusqu’à ce que la réponse revienne. Ce guide couvre en détail l’échantillonnage basé sur la fin.

La plupart des organisations ont généralement recours à un mécanisme d’échantillonnage probabiliste basé sur l’en-tête, avec un taux d’échantillonnage de 1 à 3 %. Voir ici comment configurer un échantillonnage à taux fixe avec OTel.

Soyez sélectif dans la mise en œuvre du suivi personnalisé

Le suivi distribué est puissant car il nous permet de signaler des segments de suivi personnalisés. Les segments personnalisés nous permettent d’enrichir les traces distribuées avec des informations supplémentaires spécifiques au domaine, rendant les données de suivi plus significatives.

Il est possible de capturer et de consigner les états d’erreur en tant que partie d’un segment ou de créer des segments enfants qui décrivent davantage le fonctionnement d’un service. Les segments correctement étiquetés peuvent, à leur tour, réduire significativement le nombre de déclarations de journalisation nécessaires dans votre code.

Dans le contexte du suivi, la largeur fait référence au nombre de services ou de composants instrumentés, tandis que la profondeur fait référence au niveau de détail capturé dans chaque segment. Trouver le bon équilibre entre la largeur et la profondeur est crucial pour mettre en œuvre un mécanisme de suivi efficace tout en maîtrisant les coûts.

En général, il est judicieux d’aller aussi loin que possible et d’être sélectif dans les endroits où vous approfondissez.

Intégrez le suivi à vos systèmes de surveillance et de journalisation

Assurez-vous de connecter le suivi aux systèmes de surveillance et de journalisation existants afin de faciliter la corrélation des trois ensembles de données lors du dépannage. Cela se fait généralement par :

• Injection de journalisation : Injectez des ID de trace/ID de segment directement dans les journaux à l’aide de cadres ou de bibliothèques de journalisation. Ainsi, chaque message de journal possède un ID de trace qui peut être utilisé pour interroger facilement des journaux spécifiques.
• Étiquetage des métriques : Des étiquettes ou des libellés liés à la trace peuvent être inclus lors de l’enregistrement des métriques. Ces étiquettes peuvent être des ID de trace, des noms de segments ou d’autres métadonnées spécifiques à la trace. Cela permet aux développeurs de filtrer et d’agréger des métriques autour des données de suivi, et facilite la compréhension des systèmes distribués.

Des protocoles tels qu’OpenTelemetry vous permettent déjà de le faire facilement.

Choisissez une interface de visualisation de traces moderne

Il existe une différence significative entre les solutions en termes d’interface. Après avoir collecté des données de suivi, vous devez pouvoir les visualiser. Une bonne visualisation de suivi vous permettra de voir le flux des demandes de suivi à travers un système et d’identifier les goulots d’étranglement de performance.

Cependant, toutes les solutions de suivi ne fournissent pas une manière intuitive et conviviale de visualiser et analyser ces données directement. Certains outils excellent dans la collecte et le stockage des données de suivi mais ont une visualisation basique (par exemple, Jaeger, Zipkin, AWS XRay), tandis que d’autres se concentrent davantage sur la fourniture d’informations à partir des données de suivi et ont donc investi dans une visualisation et des analyses plus sophistiquées (par exemple, Honeycomb, Lighstep, Helios).

Les bons outils de visualisation doivent offrir des tableaux de bord prêts à l’emploi qui vous donnent automatiquement des cartes de dépendance de service, ont des visualisations de trace Gantt et waterfall, et permettent des requêtes détaillées et un filtrage des traces. Cet article est une vision bien équilibrée de la visualisation dans la traçabilité distribuée.

Explorez les outils de nouvelle génération qui combinent l’IA et la traçabilité

Avec l’évolution rapide de l’OTel, l’instrumentation est devenue assez standardisée. De même, le stockage et les requêtes sont également devenus largement standardisés dans l’industrie de l’observabilité au cours des dernières années. Aujourd’hui, il existe une certaine différenciation dans la couche de visualisation et d’analyse, bien que même cela ne soit pas significatif.

Il existe une classe émergente de solutions qui utilisent l’IA sur les données de traçabilité distribuée pour générer des inférences sur les causes des problèmes. Ces solutions ont également la pile de traçage la plus moderne et rendent la mise en œuvre et la gestion beaucoup plus simples. Par exemple, des solutions comme ZeroK vous permettent de faire ce qui suit :

• Installer la traçabilité distribuée sur tous vos composants en une seule fois sans aucun changement de code ; tous les services, les bases de données et les files d’attente sont couverts immédiatement à l’aide de l’OTel et de l’eBPF.
• Elles éliminent la nécessité de l’échantillonnage – elles traitent 100 % des traces et utilisent l’IA pour identifier automatiquement celles qui sont anormales / “intéressantes” à stocker (par exemple, les traces d’erreurs, les traces de latence élevée).
• Ajouter aux traces anormales des contextes supplémentaires (par exemple, des journaux) pour faciliter le débogage, le cas échéant.
• Appliquer des modèles d’apprentissage automatique à ces traces pour identifier automatiquement les causes probables de vos problèmes de production.

Investir dans l’intégration des développeurs

C’est un facteur souvent négligé mais critique qui contribuera au succès de la traçabilité distribuée dans votre organisation. N’oubliez pas que la traçabilité distribuée est complexe et qu’il est difficile pour les nouveaux développeurs de se familiariser avec son utilisation efficace. Il n’est pas du tout rare que les entreprises n’aient que quelques utilisateurs experts utilisant la plateforme de traçabilité, et ce seulement quelques fois par trimestre.

Les développeurs doivent apprendre à interpréter les données de traçage, à comprendre les relations entre les différents microservices et à résoudre les problèmes à l’aide d’outils de traçabilité distribuée. Il faut les guider sur les meilleures pratiques telles que des conventions de nommage cohérentes, une instrumentation appropriée et la compréhension de la propagation du contexte de traçage. La planification de l’intégration des développeurs à la traçabilité distribuée est un investissement stratégique. Cela accélère non seulement l’intégration de la traçabilité dans le système, mais favorise également une culture où les développeurs sont des acteurs actifs dans l’amélioration continue de la visibilité, de la fiabilité et des performances du système.

Conclusion

Nous avons examiné les meilleures pratiques de la traçabilité distribuée et ce que vous pouvez faire pour faciliter le parcours. La traçabilité distribuée n’est plus une nouveauté ; elle est devenue une partie cruciale de la pile d’observabilité.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!