Gestion du taux d'erreur dans OpenTelemetry et New Relic

New Relic et OpenTelemetry utilisent différentes méthodes de monitoring des performances des applications (APM) pour définir, capturer et présenter les erreurs. Lorsque les clients migrent vers OpenTelemetry et comparent les pages de synthèse de l'APM et d'OpenTelemetry, ils constatent que les graphiques pour les taux d'erreur affichent différentes valeurs pour le même service. Nous vous expliquons pourquoi dans ce billet de blog.

Qu'est-ce qu'une erreur ?

Cette question peut sembler simple. Et une explication simple peut être : toute transaction ayant une exception non traitée constitue une erreur.  

Le taux d'erreur est le pourcentage des transactions qui aboutissent à une erreur au cours d'une période donnée. Par exemple, si pendant une période spécifique, votre application traite 1 000 transactions et que 50 d’entre elles renvoient une exception non gérée, votre taux d’erreur est de 50/1 000, soit 5 %. Toutefois, les erreurs sont définies et interprétées différemment par OpenTelemetry, ce qui entraîne également une variation du taux d'erreur. Cette variation est essentiellement due au fait que la notion de transaction ainsi que la logique supplémentaire utilisée par nos agents pour capturer et compter les erreurs n'existent pas dans OpenTelemetry.  

Examinons tout d'abord la façon dont New Relic traite les erreurs pour nos agents APM et comparons-la à OpenTelemetry.

Les agents de New Relic APM

Chez New Relic, une transaction est une unité logique de travail dans une application logicielle. Elle fait référence en particulier aux appels et méthodes de fonction qui composent cette unité de travail. Pour l'APM, elle se rapporte souvent à une transaction web qui représente l'activité du moment où l'application reçoit une requête web jusqu'à l'envoi de la réponse.

En savoir plus sur les types et sous-types de transactions

La logique derrière les erreurs de transaction

Nous enregistrons une seule erreur par transaction. En effet, au nom de la clarté du taux d'erreur, même s'il y a plusieurs erreurs au sein de l'unité de travail, nous ne comptons qu'une erreur par transaction. Cela est obtenu en fonction des types d'erreurs suivants, par ordre de priorité :

• API NoticeError
• Exception observée par l'instrumentation
• Transaction web avec un code d'état >= 400

Lorsqu'une erreur est définie, l'événement TransactionError capture les détails comme le type d'exception et la trace d’appels. New Relic APM prend également en charge les notions d'erreurs « ignorées » et « attendues » par le biais de la configuration des agents.

Exemple avec New Relic

Cette transaction comporte quatre méthodes instrumentées. Les méthodes B et D contiennent des erreurs ; toutefois, cette instance n'enregistre que la première erreur et les détails basés sur l'ordre de priorité.

Lorsqu'une erreur inattendue est enregistrée, le nombre d'erreurs augmente et est enregistré en tant que métrique par l'agent New Relic APM (apm.service.error.count). Le taux d'erreur sur la page de synthèse (Summary) de l'APM est calculé en utilisant cette métrique, comme illustré dans la capture d'écran ci-dessous. Le calcul et la visualisation du taux d’erreur ne prennent pas en compte l'événement TransactionError, car il est échantillonné et constitue un dataset limité.

Exemple de requête NRQL :

Pour en savoir plus sur la gestion des erreurs pour les agents New Relic, consultez notre documentation.

OpenTelemetry

Les erreurs sont définies de deux façons à partir des données d'OpenTelemetry pour actionner différentes parties de notre interface :

1. Les métriques d'OpenTelemetry, qui sont utilisées pour le graphique sur le taux d’erreur sur la page de synthèse de l'APM d'OpenTelemetry.
2. Les transactions définies à partir des spans, qui sont utilisées pour Errors Inbox.

Les erreurs provenant des métriques (synthèse de l'APM d'OpenTelemetry)

Sur la page de synthèse d'OpenTelemetry dans New Relic, vous avez la possibilité de basculer entre les métriques et les spans.  

Métriques : une différence clé entre l'APM et OpenTelemetry se trouve dans le fait que les spécifications sur http metrics d'OpenTelemetry ne contiennent pas de métriques de décompte des erreurs. Pour l'expérience d'APM d'OpenTelemetry dans New Relic, le graphique sur le taux d’erreur fait référence à la métrique de durée (duration) http.server.request.duration ou rpc.server.duration et classe les instances où le code d'état >=500 en tant que taux d’erreur. Cela signifie que le taux d’erreur des métriques est limité aux appels HTTP.

Exemple de requête NRQL :

Spans : lorsque le graphique sur le taux d’erreur est dérivé pour les spans, tous les spans d'OpenTelemetry avec le type de serveur ou de consommateur et le code d'état ERROR sont considérés en tant qu'erreur. Cela signifie que le taux d’erreur des spans est agnostique aux protocoles.

Exemple de requête NRQL :

Les erreurs provenant des spans (Errors Inbox)

OpenTelemetry ne dispose pas du concept de transaction, mais il contient les spans et les spans représentent des opérations au sein d'une transaction. New Relic compte sur SpanKind pour modéliser les données de trace sur notre concept d'une transaction. Un serveur ou consommateur SpanKind est utilisé pour identifier le point d'entrée d'un processus. En d'autres termes, ces spans sont soit des spans racines soit des spans enfants d'un processus à distance.

Outre le manque de définition d'une transaction, OpenTelemetry n'inclut pas non plus de métrique de taux d'erreur explicite.

Afin de combler l'écart entre New Relic et OpenTelemetry, les transactions sont définies par un span de server kind, avec des spans enfants qui composent les sous-opérations de la transaction.

Dans cette définition d'une transaction, la transaction est seulement considérée en tant qu'erreur si le span racine du serveur kind a un code d'état (status.code) ERROR. Lorsque d'autres spans enfants renvoient un code d'état ERROR, celui-ci compte seulement s'il est présent dans le span racine. Si ce n'est pas le cas, la transaction n'est pas ajoutée au taux d’erreur.

Exemple d'OpenTelemetry

Dans cet exemple, les services sont représentés dans des cadres contenant des cercles (spans). Le service 1 appelle le service 2, et le service 2 appelle le service 3.

Le service 2 contient plusieurs méthodes instrumentées, ce qui entraîne la capture de plusieurs spans. La méthode A est le serveur kind, ou un point d'entrée pour ce service, et elle est utilisée pour définir le concept de transaction qui renseigne l'interface de l'APM. Au sein de cette abstraction, plusieurs spans ont un code d'état ERROR.

Le span racine contient une erreur, la transaction est donc considérée comme étant une erreur et est affichée dans Errors Inbox.

Récapitulatif

Une comparaison directe entre le taux d’erreur de New Relic et celui d'OpenTelemetry est impossible, car les modèles sont fondamentalement différents. Lorsque nous passons d'une méthode d'instrumentation à une autre, il est important de rétablir les bases de référence des erreurs pour votre service et de les utiliser pour vos conditions d’alerte, objectifs de niveau de service et dashboards.