• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

Cette traduction automatique est fournie pour votre commodité.

En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.

Créer un problème

Interface utilisateur OpenTelemetry APM

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 :

  1. Dans l'interface utilisateur de New Relic, accédez à All entities > Services - OpenTelemetry ou APM & Services
  2. 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 :

  1. 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
  2. Préservation des données originales: Vos données OpenTelemetry originales restent disponibles pour la personnalisation du tableau de bord et les alertes
  3. 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 :

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.method ou http.route. Par exemple, si la métrique http.server.request.duration ne possède pas l'attribut http.route, le nom de la transaction sera WebTransaction/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).

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.

Screenshot showing the right pane showing the two links for span events

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 span
  • http.status_code à partir des conventions sémantiques HTTP span
  • http.response.status_code à partir des conventions sémantiques HTTP span
  • undefined si 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.id
  • entity.guid
  • host.name
  • instrumentation.provider
  • k8s.cluster.name
  • k8s.container.name
  • k8s.namespace.name
  • k8s.pod.name
  • service.instance.id
  • service.name

Métrique: apm.service.transaction.duration

Nom

Type d'instrument

Unité (UCUM)

Description

apm.service.transaction.duration

Distribution

s, ms, ns [1]

Durée des transactions. [2]

Attribut

Type

Description

Exemple

transactionName

string

Le nom de la transaction.

WebTransaction/server/GET /users/:id, OtherTransaction/consumer/unknown

transactionType

string

Le type de transaction.

Web, Other

error.type

string

Décrit une classe d’erreur avec laquelle la transaction s’est terminée.

500, TimeoutException

[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

transactionName

transactionType

error.type

OtelHttpServer1_23

http.server.request.duration

http.request.method IS NOT NULL

WebTransaction/server/${http.request.method} ${http.route}

Web

${error.type}

OtelHttpServer1_20

http.server.duration

http.method IS NOT NULL

WebTransaction/server/${http.method} ${http.route}

Web

__http_error_status_code_or_null__

OtelRpcServer1_20

rpc.server.duration

rpc.system IS NOT NULL

WebTransaction/server/${rpc.system}/${rpc.service:-unknown}.${rpc.method:-unknown}

Web

__rpc_error_status_code_or_null__

Métrique: apm.service.transaction.overview

Nom

Type d'instrument

Unité (UCUM)

Description

apm.service.transaction.overview

Résumé

s

Temps de décomposition du segment d'une transaction.

Attribut

Type

Description

Exemple

transactionName

string

Le nom de la transaction.

WebTransaction/server/GET /users/:id, OtherTransaction/consumer/unknown

transactionType

string

Le type de transaction.

Web, Other

attribut de domaine

divers

attribut spécifique au domaine dépendant de la convention source, notamment : db.system, db.sql.table, db.operation, external.host

Voir apm.service.external.host.duration, apm.service.datastore.operation.duration

Sources d'envergure

Convention sémantique

Type d'envergure

Conditions

transactionName

transactionType

attribut de domaine

OtelHttpServer1_23

server

http.request.method IS NOT NULL

WebTransaction/server/${http.request.method} ${http.route}

Web

OtelHttpServer1_20

server

http.method IS NOT NULL

WebTransaction/server/${http.method} ${http.route}

Web

OtelRpcServer1_20

server

rpc.system IS NOT NULL

WebTransaction/server/${rpc.system}/${rpc.service:-unknown}.${rpc.method:-unknown}

Web

OtelMessagingConsumer1_24

consumer

messaging.operation IS NOT NULL

OtherTransaction/consumer/${messaging.operation:-unknown}/${messaging.destination.template:-${messaging.destination.name:-unknown}}

Other

OtelDbClient1_33

internal
client

db.system.name IS NOT NULL

transactionName de l'envergure locale des racines

transactionType de l'envergure locale des racines

db.system: ${db.system.name}
db.sql.table: ${db.stored_procedure.name:-${db.collection.name:-${__db_summary_to_sql_table__}}}
db.operation: ${db.operation.name:-${__db_summary_to_operation__:-unknown}}

OtelDbClientRedis1_24

client

db.system IS NOT NULL
db.system = 'redis'

transactionName de l'envergure locale des racines

transactionType de l'envergure locale des racines

db.system: ${db.system}
db.sql.table: ${db.sql.table}
db.operation: ${db.operation:-${name:-unknown}}

OtelDbClient1_24

client

db.system IS NOT NULL

transactionName de l'envergure locale des racines

transactionType de l'envergure locale des racines

db.system: ${db.system}
db.sql.table: ${db.sql.table}
db.operation: ${db.operation:-unknown}

OtelHttpClient1_23

client

http.request.method IS NOT NULL

transactionName de l'envergure locale des racines

transactionType de l'envergure locale des racines

external.host: ${server.address:-unknown}

OtelHttpClient1_20

client

http.method IS NOT NULL

transactionName de l'envergure locale des racines

transactionType de l'envergure locale des racines

external.host: ${net.peer.name:-unknown}

OtelRpcClient1_20

client

rpc.system IS NOT NULL

transactionName de l'envergure locale des racines

transactionType de l'envergure locale des racines

external.host: ${net.peer.name:-unknown}

Métrique: apm.service.external.host.duration

Nom

Type d'instrument

Unité

(UCUM)

Description

apm.service.external.host.duration | | |

Distribution

s, ms, ns [1]

Durée des appels externes.

Attribut

Type

Description

Exemple

external.host

string

Domaine du serveur si disponible sans recherche DNS inversée ; sinon, adresse IP ou nom de socket de domaine Unix

example.com, 10.1.2.80, /tmp/my.sock

[1]: L'unité de la métrique source est copiée.

Sources métriques

Convention sémantique

Nom métrique

Conditions

external.host

OtelHttpClient1_23

http.client.request.duration

http.request.method IS NOT NULL

${server.address:-unknown}

OtelHttpClient1_20

http.client.duration

http.method IS NOT NULL

${net.peer.name:-unknown}

OtelRpcClient1_20

rpc.client.duration

rpc.system IS NOT NULL

${net.peer.name:-unknown}

Métrique: apm.service.datastore.operation.duration

Nom

Type d'instrument

Unité (UCUM)

Description

apm.service.datastore.operation.duration

Distribution

s, ms, ns [1]

Durée des appels datastore.

[1]: L'unité de la métrique source est copiée.

Attribut

Type

Description

Exemple

db.system

string

Le produit du système de gestion de base de données (SGBD) tel qu'identifié par l'instrumentation client.

postgresql, mysql, mariadb

db.sql.table

string

Le nom d'une collection (table, conteneur) dans la base de données.

public.users, customers

db.operation

string

Le nom de l'opération ou de la commande en cours d'exécution.

findAndModify, HMSET, SELECT

db.query.summary

string

Résumé de faible cardinalité d'une requête de base de données.

SELECT wuser_table, INSERT shipping_details, SELECT order

Sources métriques

Convention sémantique

Nom métrique

Conditions

db.system

db.sql.table

db.operation

db.query.summary

OtelDbClient1_33

db.client.operation.duration

db.system.name IS NOT NULL

${db.system.name}

${db.stored_procedure.name:-${db.collection.name:-${__db_summary_to_sql_table__}}}

${db.operation.name:-${__db_summary_to_operation__:-unknown}}

${db.query.summary}

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

__http_error_status_code_or_null__

Renvoie la valeur de chaîne de http.status_code if >= 500

__rpc_error_status_code_or_null__

Renvoie la valeur de chaîne de rpc.grpc.status_code si dans l'ensemble : [2,4,12,13,14,15]

__db_summary_to_operation__

Renvoie le premier mot de db.query.summary dans l'ensemble (insensible à la casse) : [alter,call,create,delete,drop,exec,execute,insert,merge,select,set,update]

__db_summary_to_sql_table__

Renvoie le premier mot de db.query.summary NON dans l'ensemble (insensible à la casse) : [alter,call,create,delete,drop,exec,execute,insert,merge,select,set,update]

__null__

Espace réservé pour null

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.

Droits d'auteur © 2025 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.