L'interface utilisateur OpenTelemetry APM offre une expérience monitoring complète pour les services instrumentés avec OpenTelemetry, offrant les mêmes puissantes capacités APM que vous attendez des agents de langage traditionnels de New Relic.
Prérequis
Avant d'utiliser l'interface utilisateur OpenTelemetry APM, assurez-vous d'avoir :
- Configurez votre service avec l'instrumentation OpenTelemetry
- Configurez votre service pour envoyer des données à New Relic
- Entité de serviceOpenTelemetry créée
Si vous n’avez pas effectué ces étapes, consultez le monitoring OpenTelemetry APM pour obtenir des instructions de configuration.
Trouvez vos services OpenTelemetry
Pour localiser vos services instrumentés OpenTelemetry :
- Dans l'interface utilisateur de New Relic, accédez à All entities > Services - OpenTelemetry ou APM & Services
- Sélectionnez un service pour ouvrir sa page Summary
Conseil
Utilisez la balise entité dans l’explorateur d’entités pour filtrer les services. Apprenez-en plus sur la façon dont les balises d'entité sont calculées dans les ressources OpenTelemetry dans New Relic.
Comment OpenTelemetry fonctionne avec New Relic APM
Les services instrumentés par OpenTelemetryoffrent la même expérience APM organisée que les services utilisant les agents de langage de New Relic. Voici comment cela fonctionne :
Processus de modélisation des données
New Relic mappe automatiquement vos données OpenTelemetry à nos conventions APM en :
- Génération de métriques APM: Nous créons les métriques nécessaires à l'expérience APM directement à partir de vos données OpenTelemetry
- Préservation des données originales: Vos données OpenTelemetry originales restent disponibles pour la personnalisation du tableau de bord et les alertes
- Conventions de normalisation: nous gérons les conventions sémantiques évolutives d'OpenTelemetry afin que vous n'ayez pas à suivre les différences de version
Avantages pour les utilisateurs New Relic existants
Si vous passez des agents New Relic à OpenTelemetry, vous pouvez continuer à utiliser des métriques et des requêtes familières tout en adoptant les normes OpenTelemetry.
Important
Pourquoi nous normalisons les données OpenTelemetry
Les conventions sémantiques d'OpenTelemetry sont encore en évolution, et beaucoup ne sont pas encore stables. En normalisant vos données selon les conventions New Relic, nous :
- Réduisez la complexité du suivi des versions de convention OpenTelemetry utilisées par votre instrumentation
- Offrez une expérience cohérente lors de votre transition des agents New Relic vers OpenTelemetry
- Assurez-vous que votre expérience APM reste stable quelles que soient les modifications d'OpenTelemetry
Sources de données et priorisation
L'expérience APM utilise trois types de données OpenTelemetry :
- Métriques (primaires) : fournit des statistiques de service précises telles que le débit, le temps de réponse et le taux d'erreur
- Spans (supplémentaires) : utilisées lorsque les métriques ne sont pas disponibles ou pour des fonctionnalités spécifiques comme le suivi des transactions
- Logs: Intégré pour le dépannage et la corrélation
Pourquoi les métriques sont préférées: les métriques donnent une image complète des performances de votre service, tandis que les étendues sont généralement échantillonnées et peuvent ne pas représenter tout le trafic.
L'expérience APM s'appuie principalement sur ces conventions sémantiques OpenTelemetry :
- HTTP - transaction Web et appels externes
- RPC - Appels de procédure à distance
- Messagerie - fichier d'attente des messages opérations
- base de données - base de données opérations
Comment les transactions sont dérivées des données OpenTelemetry
L'expérience APM de New Relic est centrée sur la notion de transaction. Lors de l'utilisation d'un agent New Relic, il incombe à l'instrumentation de l'agent de définir la portée d'une transaction (par exemple, une seule requête Web). L'agent produit des données métriques qui pilotent la grande majorité de l'expérience New Relic APM en enregistrant les métriques de transaction mesurant la durée des transactions et ses opérations individuelles (par exemple, les appels externes et les appels de base de données).
L'instrumentation OpenTelemetry n'a pas d'analogue direct à une transaction New Relic, il est donc essentiel d'adapter la notion de transactions aux données OpenTelemetry.
En exploitant les conventions sémantiques d'OpenTelemetry, nous pouvons tirer parti des moyens hautement structurés et standardisés d'OpenTelemetry pour décrire la télémétrie afin de piloter l'expérience APM d'une manière très similaire à celle des agents de New Relic.
Les conventions sémantiques définissent des métriques standard pour mesurer des opérations courantes telles que la gestion requests HTTP ou RPC. Ces métriques sont analogues aux métriques de transaction que les agents New Relic produisent pour décrire le Web de transaction. Nous exploitons les métriques HTTP et RPC d'OpenTelemetry pour synthétiser les métriques qui pilotent l'interface utilisateur APM telles que la métriqueapm.service.transaction.duration .
New Relic fournit également une notion de transaction non Web. Les transactions non Web sont couramment utilisées pour les systèmes qui effectuent le traitement des messages. L'instrumentation qui exploite les conventions de messagerie d' OpenTelemetrypermettra de synthétiser des métriques représentant des transactions non Web.
Important
Opérations de messagerie et données étendues
Les conventions de messagerie d'OpenTelemetry sont moins matures que les conventions HTTP et RPC. Actuellement, nous générons des métriques de transaction non Web pour les opérations de messagerie à partir de données span plutôt que de données métriques. Cette approche suit les conventions sémantiques de messagerie mais peut être affectée par votre stratégie d’échantillonnage.
Noms des transactions
Chaque transaction a un nom dérivé de l'attribut requis par les conventions sémantiques d' OpenTelemetry. Reportez-vous à la section Métriques du service APM pour savoir comment ce nom est dérivé.
Nom de transaction inconnu
Parfois, vous pouvez voir une transaction avec unknown dans le nom. Ceci indique que les données sources utilisées pour dériver la transaction ne suivent aucune des conventions sémantiques OpenTelemetry établies que nous prenons actuellement en charge.
Quelques exemples :
- Métriques HTTP manquantes :
http.request.methodouhttp.route. Par exemple, si la métriquehttp.server.request.durationne possède pas l'attributhttp.route, le nom de la transaction seraWebTransaction/server/GET unknown. - Frameworks ou protocoles pour lesquels OpenTelemetry ne définit pas actuellement de conventions sémantiques (par exemple, les tâches d'arrière-plan et le cadre CI).
Naviguer dans l'expérience APM
Résumé
La page Summary fournit un aperçu de l'état de votre service et est centrée sur la notion de transaction de New Relic. Consultez Comment les transactions sont dérivées des données OpenTelemetry pour plus de détails.
Les métriques New Relic qui pilotent la page Summary sont les métriques apm.service.transaction.duration et apm.service.error.count. Consultez-les pour plus de détails sur la manière dont ils sont dérivés de vos données OpenTelemetry.
Personnalisation de la cible Apdex
Dans l'instrumentation New Relic, les cibles apdex personnalisées sont configurées à l'aide de configuration de l'agent. Pour OpenTelemetry, lorsque vous visualisez un service, accédez à Settings > Application pour configurer votre cible Apdex.
Tracing distribué
La page de tracing distribué fournit des informations détaillées sur les OpenTelemetry trace données . Voir le tracing distribué pour les informations sur l'utilisation des pages. Consultez OpenTelemetry la trace dans New Relic pour plus de détails sur la manière dont OpenTelemetry trace les données sont ingérées dans New Relic.
Comme pour les signaux dorés, les intervalles sont classés comme des erreurs si l'état de l'intervalle est défini sur ERROR (par exemple, otel.status_code = ERROR). Si l'étendue est une erreur, la description de l'état de l'étendue (par exemple, otel.status_description) s'affiche dans error details.
OpenTelemetry span événement attache des informations de contexte d'événement supplémentaires à un span particulier. Ils sont le plus souvent utilisés pour capturer des informations sur les exceptions. Si disponible, vous pouvez afficher l'événement d'un span dans les détails de trace.
Conseil
La présence d'un événement d'exception d'étendue ne qualifie pas l'étendue comme une erreur à elle seule. Seules les étendues dont le statut d'étendue est défini sur ERROR sont classées comme des erreurs.
Cartographie des services
La page de cartographie des services fournit une représentation visuelle de l’ensemble de votre architecture. Consultez les cartes de service pour plus d'informations.
Transactions
La page des transactions fournit des outils permettant d'identifier les problèmes et d'analyser les transactions d'un service.
OpenTelemetry n'a pas d'analogue direct à la notion de transaction de New Relic. Consultez Comment les transactions sont dérivées des données OpenTelemetry pour plus de détails.
Les métriques New Relic qui pilotent la page Transaction sont les métriques apm.service.transaction.duration et apm.service.error.count. Consultez-les pour plus de détails sur la manière dont ils sont dérivés de vos données OpenTelemetry.
Trace de transaction
les traces de transaction pour OpenTelemetry sont dérivées de vos données span. Sur la page des transactions, vous pouvez trouver une liste des traces de transaction. Cette liste nécessite que les données d'étendue et les données métriques pour une transaction donnée soient corrélées ensemble. Nous le faisons en ajoutant un attribut transaction.name à la portée racine d’une trace de transaction.
Répartition des segments
Cliquer sur une transaction ouvre une vue détaillée de la transaction révélant une répartition des segments. Contrairement aux agents New Relic, OpenTelemetry n'émet pas de métriques pour des segments individuels. Par conséquent, les métriques New Relic requises pour piloter la répartition des segments sont dérivées des données d'étendue.
L’inconvénient majeur du calcul de la répartition des segments à partir des données de portée est que les portées sont généralement échantillonnées. Cependant, même avec l'échantillonnage, la répartition des segments peut toujours vous aider à identifier les méthodes ou opérations spécifiques qui consomment le plus de temps au sein d'une transaction.
À partir des données d'étendue, nous estimons un taux d'échantillonnage en calculant un débit basé sur les données d'étendue reçues et en le divisant par le débit réel tel que rapporté par vos données métriques. Le taux d’échantillonnage estimé nous permet d’extrapoler la répartition des segments d’une transaction.
Ce processus n’est pas parfait et peut être affecté par un certain nombre de facteurs, notamment votre stratégie d’échantillonnage. Cela fonctionne mieux lorsque vous échantillonnez strictement un pourcentage de vos données de portée. Toutefois, par exemple, si vous échantillonnez uniquement les intervalles représentant des erreurs, la répartition des segments peut être biaisée.
base de données
La page base de données fournit des outils permettant d'identifier les problèmes et d'analyser les opérations client de base de données d'un service.
L'instrumentation OpenTelemetry représente les appels à la base de données en utilisant les conventions sémantiques de la base de données.
La métrique New Relic qui pilote la page de base de données est la métrique apm.service.datastore.operation.duration. Consultez-le pour plus de détails sur la manière dont il est dérivé de vos données OpenTelemetry.
Consommation de temps par appelant
Lorsque vous cliquez sur un appel de base de données spécifique, vous verrez le graphique « Consommation de temps par appelant ». Ce graphique est piloté par la métrique apm.service.transaction.overview. Il s’agit de la même métrique qui pilote la vue de répartition des segments de la page de transaction et elle est dérivée des données d’étendue.
Important
Les conventions sémantiques de la base de données d'OpenTelemetry ont récemment été jugées stables. Il n'existe pas encore beaucoup d'instrumentations stables, et l'instrumentation qui existe n'émet souvent que des données d'envergure et aucune donnée métrique.
Ainsi, lors de l'utilisation d'une instrumentation qui n'a pas encore adopté les conventions sémantiques stables, les métriques APM générées pilotant la page de base de données sont dérivées des données span.
Au fur et à mesure que l'instrumentation stable devient disponible et que vous l'adoptez, la page de base de données commencera à exploiter les données métriques OpenTelemetry. Contactez la communauté OpenTelemetry concernant la disponibilité d'une instrumentation de base de données stable dans votre langue.
Services externes
La page des services externes fournit des outils permettant d'identifier les problèmes et d'analyser les appels externes d'un service, notamment l'entité appelante (services en amont) et l'entité appelée (services en aval).
L'instrumentation OpenTelemetry représente les appels vers des services externes à l'aide des conventions sémantiques HTTP et RPC.
La métrique New Relic qui pilote la page de base de données est la métrique apm.service.external.host.duration. Consultez-le pour plus de détails sur la manière dont il est dérivé de vos données OpenTelemetry.
Consommation de temps par appelant
Lorsque vous cliquez sur un appel externe spécifique, vous verrez le graphique « Consommation de temps par appelant ». Ce graphique est piloté par la métrique apm.service.transaction.overview. Il s’agit de la même métrique qui pilote la vue de répartition des segments de la page de transaction et elle est dérivée des données d’étendue.
Environnement d'exécution JVM
La page d'exécution JVM fournit des outils permettant d'identifier les problèmes et d'analyser la JVM d'un service Java. La page s'affiche uniquement pour les services utilisant OpenTelemetry Java. Afin de différencier les différentes instances de service, la page nécessite que l'attribut de ressource service.instance.id soit défini (voir Services pour plus de détails).
La page d'exécution JVM affiche les signaux dorés ainsi que les mesures d'exécution JVM pour corréler les problèmes d'exécution avec l'utilisation du service.
La requête suppose que les données sont conformes aux conventions sémantiques métriquesJVM . Notez que ces conventions sont intégrées dans la bibliothèque d'instrumentation d'exécution Java OpenTelemetry, qui est automatiquement incluse avec l'agent Java OpenTelemetry.
Exécution Go
La page d'exécution Go fournit des outils permettant d'identifier les problèmes et d'analyser l'exécution d'un service Go. La page s'affiche uniquement pour les services utilisant OpenTelemetry Go. Afin de différencier les différentes instances de service, la page nécessite que l'attribut de ressource service.instance.id soit défini (voir Services pour plus de détails).
La page d'exécution Go affiche les signaux dorés ainsi que les métriques d'exécution Go pour corréler les problèmes d'exécution avec l'utilisation du service.
La requête suppose que les données sont produites par la bibliothèque d'instrumentation d'exécutionOpenTelemetry Go. Notez qu’il n’existe actuellement aucune convention sémantique pour les métriques d’exécution Go.
Logs
La page des logs fournit des outils permettant d'identifier les problèmes et d'analyser les logs d'un service. Voir Utiliser l'interface utilisateur des logs pour plus d'informations.
Errors Inbox
La page Boîte de réception des erreurs fournit des outils permettant de détecter et de trier les erreurs d'un service. Pour plus de détails, consultez Prise en main de la boîte de réception des erreurs .
La page Boîte de réception des erreurs est pilotée par des données trace. Comme pour les signaux dorés, les intervalles sont classés comme des erreurs si l'état de l'intervalle est défini sur ERROR (par exemple, otel.status_code = ERROR).
Les plages d'erreur sont regroupées par leur empreinte d'erreur, calculée en normalisant les valeurs d'identification telles que les UUID, les valeurs hexadécimales, les adresses e-mail, etc. Chaque plage d’erreur distincte est une instance individuelle au sein du groupe d’erreurs. Le message du groupe d'erreur est déterminé comme suit :
- Description de l'état de l'étendue (par exemple,
otel.status_description) rpc.grpc.status_codeà partir des conventions sémantiques RPC spanhttp.status_codeà partir des conventions sémantiques HTTP spanhttp.response.status_codeà partir des conventions sémantiques HTTP spanundefinedsi aucun des éléments ci-dessus n'est présent
Vue Span (héritage)
Dans le passé, les services instrumentés OpenTelemetry offraient une expérience utilisateur entièrement différente de celle des agents de langage de New Relic. Cette expérience plus ancienne a fourni des graphiques organisés à partir de données de portée. Les données Span sont généralement échantillonnées, elles peuvent donc être trompeuses, en particulier lorsqu'elles représentent des éléments tels que le débit.
Pour l'instant, l'ancienne expérience utilisateur est toujours disponible via la page Span View (héritée). En haut, il contient quatre onglets : Résumé, Transactions, base de données et Services externes. Tous les graphiques de ces onglets sont générés à partir de données de portée.
Conseil
Vue héritée basée sur l'étendue
Notre ancienne expérience OpenTelemetry APM permettait de visualiser les données à la fois sous l'angle métrique et sous l'angle de l'étendue. Étant donné que les données de portée sont généralement échantillonnées, les métriques fournissent des mesures de débit et de temps de réponse plus précises. La vue basée sur l'étendue est toujours disponible mais sera progressivement supprimée. Voir Span View (Legacy) pour plus de détails.
Métriques New Relic APM dérivées des données span
Les métriques New Relic APM qui pilotent l'expérience APM sont généralement dérivées de données métriques. Cependant, il existe quelques scénarios dans lesquels les métriques APM sont dérivées des données d'étendue. Pour les scénarios suivants, notez que la stratégie d'échantillonnage que vous utilisez influencera les métriques générées.
Répartition des segments
La vue de répartition des segments de transaction est pilotée à partir des données de portée. Voir la répartition des segments pour plus d'informations.
Appels de base de données
Les conventions sémantiques de la base de données OpenTelemetry ont récemment été déclarées stables. Cependant, la plupart des instruments de base de données n'ont pas encore adopté les conventions stables et ne fournissent pas encore de données métriques. Par conséquent, lors de l'utilisation d'instruments plus anciens, les métriques qui pilotent la page de base de données sont générées à partir des données d'étendue. Nous vous encourageons à effectuer une mise à niveau vers la dernière instrumentation de base de données stable dès qu'elle sera disponible pour votre langue.
Système de messagerie
Les conventions sémantiques de messagerie OpenTelemetry sont encore en développement. La plupart des instruments de messagerie n'émettent pas encore de données métriques. New Relic représente les interactions avec le système de messagerie en tant que transaction non Web. Consultez Comment les transactions sont dérivées des données OpenTelemetry pour plus d'informations.
OpenTelemetry Ruby
OpenTelemetry prend désormais en charge les métriques pour la plupart des langages, mais Ruby est une exception notable. Pour Ruby, nous effectuons un effort de toute urgence pour générer des métriques New Relic APM à partir de données span.
Métriques de service APM
Les métriques apm.service.* pilotent l'expérience APM de New Relic. Les sections suivantes décrivent les données OpenTelemetry source utilisées pour dériver apm.service.* métriques.
Attributs de ressource métrique
Les attributs de ressource suivants sont copiés à partir des données sources vers les métriques APM :
container.identity.guidhost.nameinstrumentation.providerk8s.cluster.namek8s.container.namek8s.namespace.namek8s.pod.nameservice.instance.idservice.name
Métrique: apm.service.transaction.duration
Nom | Unité (UCUM) | Description | |
|---|---|---|---|
| Distribution |
| Durée des transactions. [2] |
Attribut | Type | Description | Exemple |
|---|---|---|---|
|
| Le nom de la transaction. |
|
|
| Le type de transaction. |
|
|
| Décrit une classe d’erreur avec laquelle la transaction s’est terminée. |
|
[1]: L'unité de la métrique source est copiée.
[2]: Si error.type est résolu en non nul, apm.service.error.count est incrémenté avec le nombre respectif des données source.
Sources métriques
Convention sémantique | Nom métrique | Conditions |
|
|
|
|---|---|---|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
Métrique: apm.service.transaction.overview
Nom | Unité (UCUM) | Description | |
|---|---|---|---|
| Résumé | s | Temps de décomposition du segment d'une transaction. |
Attribut | Type | Description | Exemple |
|---|---|---|---|
|
| Le nom de la transaction. |
|
|
| Le type de transaction. |
|
attribut de domaine | divers | attribut spécifique au domaine dépendant de la convention source, notamment : | Voir |
Sources d'envergure
Convention sémantique | Type d'envergure | Conditions |
|
| attribut de domaine |
|---|---|---|---|---|---|
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
Métrique: apm.service.external.host.duration
Nom | Unité | (UCUM) | Description | |
|---|---|---|---|---|
| Distribution |
| Durée des appels externes. |
Attribut | Type | Description | Exemple |
|---|---|---|---|
|
| Domaine du serveur si disponible sans recherche DNS inversée ; sinon, adresse IP ou nom de socket de domaine Unix |
|
[1]: L'unité de la métrique source est copiée.
Sources métriques
Convention sémantique | Nom métrique | Conditions |
|
|---|---|---|---|
|
|
| |
|
|
| |
|
|
|
Métrique: apm.service.datastore.operation.duration
Nom | Unité (UCUM) | Description | |
|---|---|---|---|
| Distribution |
| Durée des appels datastore. |
[1]: L'unité de la métrique source est copiée.
Attribut | Type | Description | Exemple |
|---|---|---|---|
|
| Le produit du système de gestion de base de données (SGBD) tel qu'identifié par l'instrumentation client. |
|
|
| Le nom d'une collection (table, conteneur) dans la base de données. |
|
|
| Le nom de l'opération ou de la commande en cours d'exécution. |
|
|
| Résumé de faible cardinalité d'une requête de base de données. |
|
Sources métriques
Convention sémantique | Nom métrique | Conditions |
|
|
|
|
|---|---|---|---|---|---|---|
|
|
|
|
|
|
Fonctions d'assistance
Les fonctions d'assistance sont des références à des éléments de logique de modélisation d'attributs qui sont plus complexes que de simples références d'attributs.
Fonction | Description |
|---|---|
| Renvoie la valeur de chaîne de |
| Renvoie la valeur de chaîne de rpc.grpc.status_code si dans l'ensemble : |
| Renvoie le premier mot de |
| Renvoie le premier mot de |
| Espace réservé pour |
Signaux dorés
Les signaux dorés de débit, de temps de réponse et de taux d'erreur apparaissent à plusieurs endroits dans l'interface utilisateur d'OpenTelemetry APM. Lorsqu'ils sont utilisés, ils sont calculés comme suit :
Pour les métriques, la requête suppose que les données sont conformes aux conventions sémantiques HTTP métrique ou RPC métrique .
Pour les étendues, les requêtes sont génériques et utilisent uniquement le modèle de données d'étendue de niveau supérieur. Les spans sont comptabilisés dans le débit et le temps de réponse s'ils sont des spans d'entrée racine dans un service, calculés à l'aide d'une heuristique de WHERE span.kind = server OR span.kind = consumer. Les étendues sont des erreurs si elles ont un code d'état de ERROR (par exemple, otel.status_code = ERROR).
Affiner les données avec des filtres
Plusieurs pages incluent une barre de filtre, avec des options telles que Narrow data to.... Cela vous permet de filtrer les requêtes sur la page pour correspondre aux critères. Par exemple, vous pouvez restreindre votre recherche à un déploiement Canary particulier en filtrant sur service.version='1.2.3-canary'. Les filtres sont conservés lors de la navigation entre les pages.
métriques dorées
Les métriques dorées sont des versions à faible cardinalité des données de signaux dorés, telles que les métriques HTTP/RPC. Ils peuplent diverses expériences de plateforme, notamment l'entité Explorer, la page d'activité de la charge de travail et la page Détails du suivi des changements. Ces métriques utilisent des noms tels que newrelic.goldenmetrics.ext.service.*.
Important
Historiquement, les métriques dorées OpenTelemetry étaient calculées à partir des travées. Les portées sont généralement échantillonnées, elles ne fournissent donc qu'une image partielle. Maintenant que les métriques sont largement disponibles, les métriques dorées sont calculées à l'aide de données métriques plutôt que de données span.