• /
  • 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

Suivi des versions avec la boîte de réception des erreurs

Le suivi des versions de la boîte de réception des erreurs permet aux développeurs de monitorer chaque déploiement pour vérifier l'exactitude et le succès. Disons que vous et votre équipe recevez une alerte indiquant que l'une de vos entités présente un pic de taux d'erreur. Vous identifiez la source de l'erreur et décidez de sortir un déploiement canary. Vous pouvez utiliser le suivi des versions pour monitorer votre correctif ainsi que le déploiement précédent afin de déterminer si vous avez résolu le problème ou si vous devez revenir à la planche à dessin.

A screenshot that depicts error occurrences by version

Triage par statut d'erreur

Lorsque vous triez votre boîte de réception, vous pouvez choisir parmi une variété de statuts. Vous souhaiterez peut-être résoudre les erreurs immédiatement ou même les marquer afin qu'elles soient ignorées. Dans d’autres cas, vous souhaiterez peut-être résoudre les problèmes dans la prochaine version ou dans une version spécifique.

Screenshot showing resolve in version

Vous pouvez définir l'un des statuts suivants et filtrer votre boîte de réception par statut :

  • Unresolved:Il s'agit de l'état par défaut des groupes d'erreurs.

  • Resolve in next version:Nous vous recommandons d'utiliser ce statut si vous espérez résoudre ce groupe d'erreurs lors de votre prochaine sortie. Afin d'activer cette option, vous devez configurer le suivi des changements pour votre application afin que Errors Inbox puisse détecter une nouvelle sortie et vérifier que le groupe d'erreurs a bien été résolu. Dans le cas où le groupe d'erreurs est toujours détecté dans la prochaine version ou dans toute version future, le groupe d'erreurs sera automatiquement résolu, marqué d'une régression et vous recevrez une notification Slack concernant la régression.

  • Resolve in specific version: Choisissez cette option pour résoudre les groupes d’erreurs dans ces situations :

    • Si vous savez que le groupe d'erreurs sera résolu dans une version spécifique
    • Si vous savez que le groupe d'erreurs est résolu dans une version existante
    • Si vous souhaitez saisir une version spécifique Pour activer cette option, vous devez instrumenter le suivi des versions pour votre application ou service. Si une occurrence d'erreur avec une version sémantique équivalente ou supérieure est détectée, le groupe d'erreurs sera automatiquement résolu, marqué d'une régression et vous recevrez une notification Slack concernant la régression.
  • Resolve: Définir un groupe d'erreurs comme résolu le masquera de la vue par défaut de la boîte de réception, sauf si les filtres sont mis à jour pour inclure les groupes d'erreurs résolus. Si un événement correspondant à l'empreinte du groupe d'erreurs se produit après avoir marqué un groupe d'erreurs comme résolu, il réinitialisera automatiquement le statut sur Non résolu. Cela peut être utile pour identifier les régressions.

  • Ignore:Cela masquera le groupe d'erreurs de la vue de la boîte de réception, sauf si les filtres sont mis à jour pour inclure l'erreur ignorée, ou jusqu'à ce que vous arrêtiez d'ignorer le groupe d'erreurs.

Conseil

Les options Resolve in next version et Resolve in specific version ne sont prises en charge que si votre équipe utilise le versionnage sémantique.

Comprendre les champs de suivi des versions

Avant de procéder au suivi des instrument, il est important de comprendre comment la boîte de réception des erreurs trie vos résultats. Dans les applications APM et OpenTelemetry, lorsque vous suivez les erreurs, les champs d'événement suivants sont vérifiés et affichés dans cet ordre:

  1. service.version
  2. tags.service.version
  3. tags.releaseTag
  4. tags.commit

Pour les applications mobiles, le champ d'événement est appVersion.

Pour les applications de navigateur, le champ d’événement est application.version.

suivi de la version de l'instrument

Pour capturer les données de notre suivi de version, vous devez configurer les champs pour l'entité concernée :

Filtrer par version

Une fois que vous avez instrumenté le suivi des versions, vos groupes d'erreurs captureront automatiquement les données de chaque sortie. Vous pouvez filtrer par chaque version.

Pour filtrer les groupes d’erreurs avec plusieurs versions, utilisez l’opérateur + pour choisir une condition OR .

A screenshot depicting how to filter by versions in errors inbox.

Vous pouvez utiliser le suivi des changements pour monitorer votre déploiement. Si vous avez fait cela, il est important de vous assurer que votre déploiement correspond au même format de version que vous avez instrumenté sur votre entité afin que vous puissiez faire correspondre les versions de vos erreurs à votre déploiement.

Rechercher des versions par groupe d'erreurs

Vous pouvez également cliquer sur un groupe d’erreurs pour voir chaque déploiement qui correspond aux dates de première et de dernière apparition de votre groupe d’erreurs. Vous ne verrez que les versions qui ont été mises en ligne dans les 30 minutes suivant votre première date de visionnage et dans les 30 minutes précédant votre dernière date de visionnage.

A screenshot depicting last seen date of errors

Vous pouvez approfondir vos groupes d’erreurs en utilisant le graphique qui montre chacune de vos occurrences d’erreur regroupées par version.

Si vous avez également mis en place une déploiement avec suivi des changements, vous verrez marqueur de déploiement sur ce tableau. Ces marqueurs indiquent quand chaque déploiement a eu lieu. Cliquez sur le marqueur pour accéder au déploiement.

Droits d'auteur © 2025 New Relic Inc.

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