Auparavant, il était facile de déduire et de déboguer un problème dans les applications monolithiques car il n’y avait qu’un seul service en cours d’exécution dans le back-end et le front-end. Maintenant, nous nous dirigeons vers une architecture de microservices, où les applications sont divisées en plusieurs services déployables indépendamment. Ces services ont leur propre objectif et logique à servir. Dans ce type d’architecture d’application, il devient difficile d’observer comment un service dépend ou affecte d’autres services.
Pour rendre le système observable, certains journaux, métriques ou traces doivent être émis à partir du code, et ces données doivent être envoyées à un back-end d’observabilité. C’est là qu’OpenTelemetry et Jaeger entrent en scène.
Dans cet article, nous verrons comment surveiller les données de trace des applications (Traces et Spans) à l’aide d’OpenTelemetry et de Jaeger. Une trace est utilisée pour observer les requêtes au fur et à mesure qu’elles se propagent dans les services d’un système distribué. Les portées sont une unité de base de la trace ; ils représentent un événement unique dans la trace, et une trace peut avoir une ou plusieurs étendues. Une étendue se compose de messages de journal, de données temporelles et d’autres attributs pour fournir des informations sur l’opération qu’elle suit.
Nous utiliserons la méthode de traçage distribué pour observer les requêtes se déplaçant à travers les microservices, en générant des données sur la requête et en les rendant disponibles pour analyse. Les données produites auront un enregistrement du flux de requêtes dans nos microservices, et cela nous aidera à comprendre les performances de notre application.
OpenTelemetry
La télémétrie est la collecte et la transmission de données à l’aide d’agents et de protocoles depuis la source en matière d’observabilité. Les données de télémétrie comprennent des journaux, des métriques et des traces, qui nous aident à comprendre ce qui se passe dans notre application.
OpenTelemetry (également connu sous le nom d’OTel) est un framework open source comprenant une collection d’outils, d’API et de SDK. OpenTelemetry facilite la génération, l’instrumentation, la collecte et l’exportation des données de télémétrie. Les données collectées à partir d’OpenTelemetry sont indépendantes du fournisseur et peuvent être exportées dans de nombreux formats. OpenTelemetry est formé après la fusion de deux projets OpenCensus et OpenTracing.
Instrumentation
Le processus d’ajout de code d’observabilité à votre application est appelé instrumentation. L’instrumentation permet de rendre notre application observable, ce qui signifie que le code doit produire des métriques, des traces et des journaux. OpenTelemetry fournit deux façons d’instrumenter notre code :
- Instrumentation manuelle
- Instrumentation automatique
1. Instrumentation manuelle
L’utilisateur doit ajouter un code OpenTelemetry à l’application. L’instrumentation manuelle offre plus d’options de personnalisation dans les portées et les traces. Les langages pris en charge pour les instrumentations manuelles sont C++, .NET, Go, Java, Python, etc.
2. Instrumentation automatique
Il s’agit de la méthode d’instrumentation la plus simple car elle ne nécessite aucune modification du code et aucune recompilation de l’application. Il utilise un agent intelligent qui s’attache à une application, lit son activité et extrait les traces. L’instrumentation automatique prend en charge Java, NodeJS, Python, etc.
Différence entre l’instrumentation manuelle et automatique
L’instrumentation manuelle et automatique présente des avantages et des inconvénients que vous pourriez prendre en compte lors de l’écriture de votre code. Quelques-uns d’entre eux sont énumérés ci-dessous :
|
Instrumentation manuelle |
Instrumentation automatique |
|---|---|
| Des changements de code sont nécessaires. | Les changements de code ne sont pas nécessaires. |
| Il prend en charge les langages de programmation maximum. | Actuellement, .Net, Java, NodeJS et Python sont pris en charge. |
| Cela prend beaucoup de temps car des changements de code sont nécessaires. | Facile à mettre en œuvre car nous n’avons pas besoin de toucher au code. |
| Fournir plus d’options pour la personnalisation des étendues et des traces. Comme vous avez plus de contrôle sur les données de télémétrie générées par votre application. | Moins d’options de personnalisation. |
| Les possibilités d’erreur sont élevées car des modifications manuelles sont nécessaires. | Aucune possibilité d’erreur. Comme nous n’avons pas à toucher à notre code d’application. |
Pour simplifier le processus d’instrumentation, utilisez l’instrumentation automatique, car elle ne nécessite aucune modification du code et réduit les risques d’erreurs. L’instrumentation automatique est effectuée par un agent qui lit les données de télémétrie de votre application, aucune modification manuelle n’est donc nécessaire.
Dans le cadre de cet article, nous verrons comment vous pouvez utiliser l’instrumentation automatique dans un environnement de microservices basé sur Kubernetes.
Jaeger
Jaeger est un outil de traçage distribué initialement construit par Uber et publié en open-source en 2015. Jaeger est également un projet d’études supérieures de la Cloud Native Computing Foundation et a été influencé par Dapper et OpenZipkin. Il est utilisé pour surveiller et dépanner les systèmes distribués basés sur des microservices.
Les composants Jaeger que nous avons utilisés pour ce blog sont :
- Collectionneur Jaeger
- Requête Jaeger
- Interface utilisateur/console Jaeger
- Back-end de stockage
Collectionneur Jaeger : Le système de traçage distribué Jaeger inclut le collecteur Jaeger. Il est chargé de collecter et de conserver les informations. Après avoir reçu des étendues, le collecteur les ajoute à une file d’attente de traitement. Les collecteurs ont besoin d’un backend de stockage persistant, c’est pourquoi Jaeger fournit également un mécanisme de stockage de plage enfichable.
Requête Jaeger : Il s’agit d’un service utilisé pour extraire des traces du stockage. L’interface utilisateur Web du système de traçage distribué Jaeger s’appelle Jaeger Query. Il fournit diverses fonctionnalités et outils pour vous aider à comprendre les performances et le comportement de votre application distribuée et vous permet de rechercher, filtrer et visualiser les données recueillies par Jaeger.
Interface utilisateur/console Jaeger : Jaeger UI vous permet de visualiser et d’analyser les traces générées par votre application.
Backend de stockage : Celui-ci sert à stocker les traces générées par une application sur le long terme. Dans cet article, nous allons utiliser Elasticsearch pour stocker les traces.
Quel est le besoin d’intégrer OpenTelemetry avec Jaeger ?
OpenTelemetry et Jaeger sont les outils qui nous aident à définir l’observabilité dans les systèmes distribués basés sur des microservices, mais ils sont destinés à résoudre différents problèmes.
OpenTelemetry fournit une couche d’instrumentation pour l’application, qui nous aide à générer, collecter et exporter les données de télémétrie pour analyse. En revanche, Jaeger est utilisé pour stocker et visualiser les données de télémétrie.
OpenTelemetry peut uniquement générer et collecter les données. Il n’a pas d’interface utilisateur pour la visualisation. Nous devons donc intégrer Jaeger à OpenTelemetry car il dispose d’un backend de stockage et d’une interface utilisateur Web pour la visualisation des données de télémétrie. Avec l’aide de Jaeger UI, nous pouvons rapidement dépanner les systèmes distribués basés sur des microservices.
Remarque : OpenTelemetry peut générer des journaux, des métriques et des traces. Jaeger ne prend pas en charge les journaux et les métriques.
Vous avez maintenant une idée sur OpenTelemetry et Jaeger. Voyons comment nous pouvons les intégrer les uns aux autres pour visualiser les traces et les spans générés par notre application.
Implémentation de l’instrumentation automatique OpenTelemetry
Nous intégrerons OpenTelemetry à Jaeger, où OpenTelemetry agira en tant que couche d’instrumentation pour notre application, et Jaeger agira en tant qu’outil d’analyse back-end pour visualiser les données de trace.
Jaeger obtiendra les données de télémétrie de l’agent OpenTelemetry. Il stockera les données dans le backend de stockage, à partir duquel nous interrogerons les données stockées et les visualiserons dans l’interface utilisateur Jaeger.
Les prérequis pour cet article sont :
- Le cluster Kubernetes cible est opérationnel.
- Vous avez accès pour exécuter le
kubectlcommande sur le cluster Kubernetes pour déployer des ressources. - Le gestionnaire de certificats est installé et en cours d’exécution. Vous pouvez l’installer depuis le site cert-manager.io s’il n’est pas installé.
Nous supposons que vous avez toutes les conditions préalables et que vous êtes maintenant prêt pour l’installation. Les fichiers que nous avons utilisés pour cet article sont disponibles dans ce référentiel GitHub.
Installation
La partie installation contient trois étapes :
- Installation d’Elasticsearch
- Installation Jaeger
- Installation d’OpenTelemetry
Recherche élastique
Par défaut, Jaeger utilise le stockage en mémoire pour stocker les étendues, ce qui n’est pas une approche recommandée pour l’environnement de production. Il existe divers outils disponibles à utiliser comme back-end de stockage dans Jaeger ; vous pouvez lire à leur sujet dans la documentation officielle de Jaeger span storage back-end.
Dans cet article, nous utiliserons Elasticsearch comme back-end de stockage. Vous pouvez déployer Elasticsearch dans votre cluster Kubernetes à l’aide du graphique Elasticsearch Helm. Lors du déploiement d’Elasticsearch, assurez-vous d’avoir activé l’authentification par mot de passe et déployez Elasticsearch dans observabilité espaces de noms.
Elasticsearch est déployé dans notre cluster Kubernetes et vous pouvez voir le résultat en exécutant la commande suivante.
$ kubectl get all -n observability
NAME READY STATUS RESTARTS AGE
pod/elasticsearch-0 1/1 Running 0 17m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/elasticsearch ClusterIP None <none> 9200/TCP,9300/TCP 17m
NAME READY AGE
statefulset.apps/elasticsearch 1/1 17mInstallation Jaeger
Nous allons utiliser Jaeger pour visualiser les données de trace. Déployons l’opérateur Jaeger sur notre cluster.
Avant de procéder à l’installation, nous allons déployer un ConfigMap dans l’espace de noms d’observabilité. Dans ce ConfigMap, nous passerons le nom d’utilisateur et le mot de passe de l’Elasticsearch que nous avons déployé à l’étape précédente. Remplacez les informations d’identification en fonction de votre configuration.
kubectl -n observability apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: jaeger-configuration
labels:
app: jaeger
app.kubernetes.io/name: jaeger
data:
span-storage-type: elasticsearch
collector: |
es:
server-urls: http://elasticsearch:9200
username: elastic
password: changeme
collector:
zipkin:
http-port: 9411
query: |
es:
server-urls:...