Tirez le meilleur parti de vos données OpenTelemetry avec New Relic

Introduction

Nous avons récemment annoncé la disponibilité générale d'APM + OpenTelemetry Convergence de New Relic, ce qui signifie que notre plateforme offre désormais une expérience d'observabilité de classe mondiale pour vos données OpenTelemetry (OTel).

Étant donné qu’OTel lui-même est un framework de collecte de données et non un backend d’observabilité, l’instrumentation n’est que la première étape du processus d’adoption. Le projet se concentre sur la question de savoir comment générer la télémétrie, mais pas ce qu’il faut en faire : pour obtenir des informations exploitables à partir des flux de données brutes produits par OTel, vous avez besoin d’une plateforme sophistiquée, évolutive et intelligente pour ingérer, stocker, corréler et visualiser ces données. 

C'est ici que New Relic entre en jeu. Dans cet article de blog, nous utiliserons le fork New Relic de l'application de démonstration d'OpenTelemetry Community, Astroshop, pour montrer comment New Relic vous aide à tirer profit de vos données OTel. 

Déploiement d'Astroshop

Astroshop est un système distribué basé sur des microservices développé dans plusieurs langues par la communauté d'OTel pour montrer l'implémentation d'OTel dans un environnement quasi réel. New Relic maintient un fork de cette application de démonstration. Pour combler le fossé entre l’instrumentation et les informations détaillées, nous avons préconfiguré notre fork pour faciliter le processus de configuration et vous permettre d’envoyer des données à votre compte New Relic presque immédiatement.

Astroshop est également équipé d'indicateurs de fonctionnalités que vous pouvez activer et désactiver pour simuler divers problèmes logiciels du monde réel. Dans l'exemple que nous utilisons dans cet article de blog, l'indicateur de fonctionnalité productcatalogfailure a été activé, ce qui signifie qu'une erreur sera générée pour les demandes GetProduct avec un identifiant de produit spécifique. 

Le déploiement de l'application de démonstration est simple. Confirmez que votre environnement répond aux prérequis, clonez le fork, puis déployez Astroshop localement à l'aide de Kubernetes ou de Docker. Validez ensuite votre déploiement et enfin, allons explorer vos données.

Pleins feux sur l'interface de New Relic

Une fois que les différents microservices Astroshop commencent le reporting des données (veuillez patienter quelques minutes après le déploiement pendant le processus de synthèse des entités), vous pouvez toutes les voir dans la vue Entities. Dans votre compte New Relic, accédez à APM & Services, cliquez sur Services - OpenTelemetry, puis cliquez sur « Tout afficher ».

Remarque : vous remarquerez que tous les services ne rapportent pas les données sur les temps de réponse, le débit et les taux d’erreur. Cela est dû à deux raisons :

• L'APM + OTel Convergence repose sur des données métriques, que tous les services ne communiquent pas encore.
• Le projet OTel présente différents niveaux d'implémentation dans les SDK et les API de langage, ce qui a eu un impact sur l'instrumentation des métriques dans certains services. 

L’interface d'APM + OTel Convergence est conçue pour apporter l'excellente expérience d'APM de New Relic aux sources de données OTel. Le mécanisme principal de cette convergence est un processus de normalisation intelligente des données : lorsque des données OTel standard sont envoyées au point de terminaison OTLP de New Relic, la plateforme produit automatiquement une copie normalisée de ces données, la conformant à nos conventions sémantiques d'APM robustes et matures. Ce processus est entièrement non destructif ; les données sources OTel originales sont préservées et disponibles pour l'interrogation, ce qui garantit une fidélité totale des données. 

Ce remplissage automatique de l'interface n'est pas un tour de magie ; c'est le résultat direct de l'adhésion aux conventions sémantiques définies par OTel et reconnues par la plateforme New Relic. New Relic utilise des attributs spécifiques attachés aux données télémétriques pour synthétiser les entités, le processus d’identification, de classification et de création d’entités telles que des services, des hôtes et des bases de données au sein de l’interface.

Le tableau suivant détaille plusieurs attributs critiques et les fonctionnalités spécifiques de New Relic qu'ils activent :

Exploration de l'interface APM + OTel Convergence

Maintenant que vous avez une compréhension de base de ce qui se passe dans les coulisses, examinons de plus près vos données Astroshop. Pour cet exemple, nous sélectionnerons le service product-catalog. En cliquant sur une entité, vous accéderez à la vue Summary de cette entité. 

Faites défiler un peu vers le bas pour voir le tableau Errors et la liste Transactions. La transaction nommée grpc/oteldemo.ProductCatalogService.GetProduct a un taux d’erreur de plus de 4 %.

Cliquez sur le bouton « View details » pour que la transaction GetProduct affiche la nouvelle vue Transaction 360, qui améliore l'analyse standard à trace unique et vous offre une vue dynamique de l'ensemble de l'écosystème des transactions. L'utilisation de cette fonctionnalité vous donne un aperçu des informations sur les performances de l'application et de l'infrastructure, y compris les alertes critiques actives et les nouvelles versions de déploiement (dans la fenêtre de temps sélectionnée). Le contexte est ce qui vous permet de corréler directement les problèmes avec le déploiement, l’hôte ou le service exact. 

Cette vue inclut la nouvelle carte de flux dynamique, qui vous permet de voir comment les données de trace circulent à travers les services. Elle utilise les données de trace pour corréler les changements de performances entre les entités en amont et en aval, par rapport à la fenêtre temporelle de correspondance précédente. 

En parcourant la vue, vous verrez des informations sur les services APM participants et les transactions qui ont participé à la trace.

Étant donné que la transaction GetProduct est signalée comme étant la cause du problème, allons plus en profondeur en cliquant sur grpc/oteldemo.ProductCatalogService.GetProduct pour ouvrir une autre vue Transaction 360 avec quelques onglets en haut.

La sélection de l’onglet « See errors » permet d’obtenir des informations supplémentaires, notamment le nombre de fois où cette erreur s’est produite. Dans la section Déploiement d'Astroshop, nous avons mentionné que l'indicateur de fonctionnalité productCatalogFailure a été activé dans l'exemple de cet article de blog. Le message pour ce groupe d'erreurs est Error: Product Catalog Fail Feature Flag Enabled (Erreur : Indicateur de fonctionnalité d'échec du catalogue de produits activé), ce qui est exactement ce à quoi nous nous attendions. 

Remarque : si vous vous demandez pourquoi le graphique du taux d’erreur ne semble afficher aucune donnée malgré l’existence évidente d’erreurs, c’est parce que ce graphique interroge spécifiquement les codes d’état HTTP de 500 ou moins. (Cliquez sur l'ellipse « … » d'un graphique pour afficher un menu vous proposant plusieurs options ; en sélectionnant « View query », vous verrez la requête exacte qui est utilisée pour générer les données de ce graphique.)

Lorsque nous quittons cette vue détaillée et revenons à la vue initiale de Transaction 360 accessible depuis la page Summary, nous pouvons cliquer sur la flèche déroulante pour développer « Supporting infrastructure entities » (Entités de support de l'infrastructure) et voir s'il y a un impact.