L'indépendance avec OpenTelemetry sur Elastic

De nos jours, les mots d'ordre concernant les services sont rapidité et scalabilité. Notre vie quotidienne se fait au rythme des applications dont elle dépend, qu'il s'agisse d'une application de livraison de repas pour commander notre plat préféré, d'une application bancaire pour gérer nos comptes, ou même d'une application pour prendre rendez-vous chez le médecin. Ces applications doivent être capables d'évoluer non seulement du point de vue des fonctionnalités, mais aussi du point de vue de la capacité utilisateur. Là où le bât blesse, c'est qu'il est devenu aujourd'hui essentiel d'avoir une envergure internationale, ce qui ne fait que renforcer la complexité de toutes ces applications cloud que nous sollicitons régulièrement.

Pour faire face à la demande, la plupart de ces applications et services en ligne (comme les applications mobiles, les pages Web, le SaaS) sont en train de passer à une architecture distribuée basée sur des microservices et à Kubernetes. Comment faire pour gérer et monitorer la production, la scalabilité et la disponibilité d'un service une fois votre application migrée vers le cloud ? OpenTelemetry est devenu rapidement la norme de facto pour l'instrumentation et la collecte de données télémétriques pour les applications Kubernetes.

OpenTelemetry (OTel) est un projet open source qui fournit une suite d'outils, d'API et de kits de développement logiciel servant à générer, collecter et exporter des données télémétriques (indicateurs, logs et traces) qui permettent de comprendre les performances et les comportements des logiciels. OpenTelemetry est récemment devenu un projet d'incubation de la CNCF. Il réunit une communauté de plus en plus importante et propose une meilleure prise en charge des fournisseurs.

Même si OTel permet d'instrumenter les applications dans un format télémétrique standard, il ne fournit pas de composants backend, ni de composants analytiques. De ce fait, avec l'utilisation de bibliothèques OTel dans les applications, l'infrastructure et le monitoring de l'expérience utilisateur, vous disposez d'une flexibilité optimale car vous pouvez choisir l'outil d'observabilité qui vous convient. Finie, la dépendance à un fournisseur pour le monitoring des performances applicatives (APM).

Elastic Observability prend en charge OpenTelemetry et son protocole (OTLP) de façon native pour ingérer des traces, des indicateurs et des logs. Toutes les fonctionnalités APM d'Elastic Observability sont disponibles avec les données OTel. En voici une liste non exhaustive :

• Cartes de service
• Détails sur les services (latence, débit, transactions ayant échoué)
• Dépendances entre les services
• Transactions (traces)
• Corrélations ML (en particulier pour la latence)
• Logs de service

En plus de l'APM et d'une vue unifiée sur les données télémétriques, vous pourrez désormais utiliser les fonctionnalités puissantes de Machine Learning d'Elastic pour réduire le temps nécessaire à une analyse, ainsi que l'alerting pour accélérer le MTTR.

Du fait de son ADN open source, Elastic prend également en charge d'autres projets de la CNCF, comme Prometheus, Fluentd, Fluent Bit, Istio, Kubernetes (K8S) et bien d'autres.  

Voici les points que nous aborderons dans cet article :

• Comment configurer une célèbre appli de démo instrumentée avec OTel (HipsterShop) pour ingérer des données dans Elastic Cloud en quelques étapes simples
• Se familiariser avec certaines fonctionnalités d'Elastic APM concernant les données OTel et découvrir les possibilités qui s'offrent à vous avec ces données une fois celles-ci dans Elastic

Dans d'autres articles à venir, nous verrons comment utiliser le Machine Learning d'Elastic avec les données télémétriques d'OTel, instrumenter les indicateurs d'application OTel pour des langues spécifiques, prendre en charge l'ingestion de Prometheus via le collecteur OTel, et bien plus encore. Restez à l'affût !

Conditions requises et configuration

Si vous comptez reproduire les étapes présentées dans cet article, voici quelques informations utiles pour la configuration :

• Vérifiez que vous disposez d'un compte Elastic Cloud et d'une pile déployée (cliquez ici pour obtenir des instructions).
• Nous avons utilisé une variante de la célèbre appli de démo HipsterShop. À l'origine, cette application a été conçue par Google pour présenter Kubernetes dans une multiplicité de variantes, comme l'appli de démo d'OpenTelemetry. Pour utiliser l'appli, cliquez ici et suivez les instructions indiquées pour la déployer.
• Sachez également que nous utilisons une version instrumentée manuellement de l'application. Aucune instrumentation automatique avec OTel n'a été utilisée lors de la configuration.
• Emplacement de nos clusters. Pour notre part, nous nous sommes servis de Google Kubernetes Engine (GKE). Mais rien ne vous empêche d'utiliser une autre plateforme Kubernetes de votre choix. 
• Même si Elastic peut ingérer des données télémétriques directement depuis des services instrumentés avec OTel, nous nous focaliserons sur le déploiement plus traditionnel, qui emploie le collecteur OpenTelemetry.
• Prometheus et FluentD/Fluent Bit – utilisés traditionnellement pour extraire toutes les données Kubernetes – ne seront pas utilisés ici par rapport à des agents Kubernetes. Ces sujets seront abordés dans des articles à venir.

Voici la configuration définie dans cet article :

Paramétrage

Dans les étapes suivantes, voici les points que nous aborderons :

• Obtenir un compte sur Elastic Cloud
• Mettre en place un cluster GKE
• Mettre en place l'application
• Configurer la configmap du collecteur OTel Kubernetes pour pointer vers Elastic Cloud
• Utiliser l'APM d'Elastic Observability avec les données OTel pour une meilleure visibilité

Étape 0 : Créer un compte sur Elastic Cloud

Suivez les instructions pour vous lancer sur Elastic Cloud.

1^ère étape : Mettre en place un cluster K8S

Pour notre part, nous nous sommes servis de Google Kubernetes Engine (GKE). Mais rien ne vous empêche d'utiliser une autre plateforme Kubernetes de votre choix.

Les données OpenTelemetry collectées ne doivent pas nécessairement provenir d'un cluster Kubernetes. N'importe quel cluster Kubernetes normal sur GKE, EKS, AKS, ou tout cluster compatible avec Kubernetes (autodéployé et géré) convient.

2e étape : Charger l'application HipsterShop sur le cluster

Déployez votre application dans un cluster Kubernetes sur le service cloud de votre choix ou sur une plateforme Kubernetes locale. Si vous le souhaitez, l'application que nous utilisons est disponible ici.

Une fois votre application prête dans Kubernetes, les pods suivants (ou d'autres similaires) s'exécuteront sur l'espace de nom par défaut.

Le résultat obtenu devrait être similaire à celui-ci :

Dans cette version, nous avons uniquement mis en avant les éléments services et loadgenerator. Comme vous pouvez le constater, nous ne nous sommes pas encore servis du collecteur OpenTelemetry. (Voir l'étape suivante.)
Si vous consultez les fichiers yaml des différents services, vous verrez qu'ils pointent vers le collecteur OpenTelemetry sur le port 4317.

Le port 4317 est le port d'écoute par défaut d'OpenTelemetry pour la télémétrie des services.  De ce fait, tous les services devraient pointer vers le collecteur OTel.

3e étape : Faire en sorte que le collecteur OpenTelemetry pointe vers Elastic

Comme vous le pouvez le voir dans le fichier otelcollector.yaml , dans /deploy-with-collector-k8s, il y a deux variables spécifiques qu'il est nécessaire de paramétrer dans la section configmap.

OTEL_EXPORTER_OTLP_ENDPOINT correspond au serveur APM d'Elastic.

OTEL_EXPORTER_OTLP_ENDPOINT fournit l'autorisation nécessaire.

Pour en savoir plus sur ces variables, consultez la documentation d'Elastic relative à la configuration du collecteur OTel.

Où obtenir ces valeurs ? 

Dans l'interface utilisateur d'Elastic Observability sous APM, +add data, l'écran suivant s'affiche. 

Accédez à l'onglet OpenTelemetry :

Vous pouvez voir les valeurs des variables OTEL_EXPORTER_OTLP_ENDPOINT (le point de terminaison du serveur APM d'Elastic) et l'autorisation de OTEL_EXPORTER_OTLP_HEADERS.

Lorsque l'on configure le collecteur OTel avec le point de terminaison du serveur APM d'Elastic, il y a deux options : gRPC et http.

Dans le fichier otelcollector.yaml ici, les exportateurs sont configurés avec http. 

Si vous souhaitez que l'acheminement se fasse depuis le port gRPC vers le serveur APM, vous devez alors modifier les exportateurs comme suit :

Comme vous pouvez le remarquer, otlphttp devient otlp. Une fois que vous avez effectué les changements nécessaires comme indiqué ci-dessus, créez otelcollector :

Vérifiez qu'il fonctionne correctement.

4^e étape : Ouvrir Kibana et utiliser la carte de service APM pour afficher vos services instrumentés par OTel

Dans l'interface utilisateur d'Elastic Observability sous APM, sélectionnez servicemap pour afficher vos services.

Si le message suivant apparaît, cela signifie que le collecteur OpenTelemetry envoie des données dans Elastic :

Congratulations, you've instrumented the HipsterShop demo application services for tracing using OpenTelemetry and successfully ingested the telemetry data into the Elastic! (Félicitations, vous avez instrumenté les services de l'appli de démo HipsterShop pour le traçage à l'aide d'OpenTelemetry et vous avez correctement ingéré les données télémétriques dans Elastic !)

Comment configurer des environnements spécifiques

Grâce à Elastic APM, vous pouvez ingérer plusieurs applications tout en ayant la possibilité d'effectuer un filtrage selon la variable environment. De ce fait, si une équipe dev team 1 et une équipe dev team 2 utilisent toutes deux l'interface utilisateur, vous devrez définir la variable environment de façon appropriée. 

Pour cette application, la variable "environment" est définie via la variable deployment.environment dans les fichiers yaml des services.

Si cela ne vous convient pas, vous devrez dans ce cas modifier OTEL_RESOURCE_ATTRIBUTES dans le fichier yaml de chaque service dans le référentiel git de l'application.

Changez :

En :

Pour appliquer cette procédure sur tous les services, exécutez la commande suivante :

5^e étape : Quelles sont les informations qu'Elastic peut me présenter ?

Maintenant que les données OpenTelemetry sont ingérées dans Elastic, que pouvez-vous faire ?

Tout d'abord, vous pouvez consulter la carte de service APM (comme indiqué dans l'étape précédente). Vous obtiendrez ainsi une vue complète de tous les services et flux de transaction entre les services.

Ensuite, vous pouvez vous renseigner sur les services individuels et les transactions collectées.

Comme vous pouvez le voir, les détails venant du frontend sont répertoriés, c'est-à-dire tout ce qui concerne les aspects suivants : 

• Latence moyenne de service
• Débit
• Principales transactions
• Taux de transactions en échec
• Erreurs
• Dépendances

Accédons à la trace. Dans l'onglet Transactions, vous pouvez consulter tous les types de transactions en lien avec le service de frontend :

Si l'on sélectionne la transaction /fr/cart/checkout par exemple, il est possible d'en voir la trace complète avec tous les intervalles :

Non seulement vous pouvez consulter cette trace, mais vous pouvez aussi analyser les facteurs qui expliquent pourquoi la latence est plus élevée que la normale pour la transaction /fr/cart/checkout.

Elastic utilise le Machine Learning pour identifier les problèmes de latence potentiels des services en s'appuyant sur la trace. Et la bonne nouvelle, c'est que c'est d'une simplicité enfantine : il vous suffit de sélectionner l'onglet Latency Correlations (Corrélations pour la latence) et de procéder à la mise en corrélation.

Nous voyons ici que les transactions du client 10.8.0.16 présentent une latence qui semble anormale pour cette transaction.

Vous pouvez plonger dans les détails des logs directement à partir de la vue de la trace afin d'identifier et de repérer les problèmes éventuels.

Analyse des données avec le Machine Learning Elastic

Une fois que les indicateurs OpenTelemetry ont été ingéré dans Elastic, commencez à analyser vos données en vous aidant des fonctionnalités de Machine Learning d'Elastic.

Pour en savoir plus sur ces fonctionnalités, lisez cet article : Correlating APM telemetry to determine root causes in transactions.

Et retrouvez encore plus de vidéos et d'articles ici.

Nous reviendrons prochainement avec d'autres articles sur les avantages du Machine Learning pour les données OpenTelemetry.

Conclusion

J'espère que cet article vous a permis de comprendre comment Elastic Observability peut vous aider à ingérer et à analyser des données OpenTelemetry avec les fonctionnalités APM d'Elastic.

Voici un récapitulatif rapide des points que nous avons vus :

• Comment configurer une célèbre appli de démo instrumentée avec OTel (HipsterShop) dans Elastic Cloud en quelques étapes simples
• Se familiariser avec certaines fonctionnalités d'Elastic APM concernant les données OTel et découvrir les possibilités qui s'offrent à vous avec ces données une fois celles-ci dans Elastic

Prêt à vous lancer ? Connectez-vous à Elastic Cloud et testez les fonctionnalités que nous venons de voir pour tirer le meilleur parti de vos données OpenTelemetry.