Pour envoyer les données d'erreur que vous gérez dans votre propre code à New Relic, utilisez l'appel Ruby API de l'agent NewRelic::Agent.notice_error dans votre gestionnaire d'erreurs.
Informez la New Relic Ruby
Cet appel d'API prend l'exception et une option hacher. Utilisez ce format :
NewRelic::Agent.notice_error(exception, options = { }) ⇒ ObjectCette fonction enregistre l'erreur donnée et la transmet via le processus de filtrage des erreurs normal, y compris l'ignorance des erreurs basée sur la configuration et la méthode globale #ignore_error_filter si elle est définie.
Le exception est l'exception à enregistrer, ou un message d'erreur. Si nécessaire, vous pouvez également inclure options = { }. Les paramètres suivants recevront un traitement spécial et tous les autres paramètres que vous fournirez seront traités comme des paramètres personnalisés.
options = { } | Comments |
|---|---|
| Enregistre uniquement la trace d'erreur. Cela n’affecte pas le taux d’erreur ni le statut Apdex. Pour plus d'informations sur les erreurs attendues dans l'UI, consultez Afficher les erreurs attendues. Remplace l'option |
| Paramètres personnalisés. |
| Le chemin de la requête, moins les paramètres de requête ou la chaîne de requête. Généralement pas nécessaire. N'incluez ceci que si vous appelez |
| Le nom de la métrique associé à la transaction. Généralement pas nécessaire. N'incluez ceci que si vous appelez |
| Les anciennes versions de l'agent Ruby permettaient de transmettre une option |
Empreintes d'erreur : appliquer dynamiquement un groupe d'erreurs à chaque erreur constatée
Vos occurrences d’erreurs sont-elles mal regroupées ? Définissez votre propre empreinte d’erreur via une fonction de rappel.
Un rappel basé sur Proc peut être fourni à l'agent pour appliquer dynamiquement un groupe d'erreurs souhaité à chaque erreur détectée. Utilisez l'API Ruby de l'agent NewRelic::Agent.set_error_group_callback pour fournir à l'agent un rappel.
Cet appel d'API prend une méthode rappel (doit être de type Proc) comme seul argument. L'argument est obligatoire. L'appel d'API ne doit être effectué qu'une seule fois par lancement de l'agent Ruby New Relic , l'appel peut donc être placé dans un initialiseur Rails ou similaire. Si des appels ultérieurs à l'API sont effectués, la méthode de rappel sera mise à jour avec la plus récente fournie. Voici un exemple de rappel défini et transmis à la méthode API NewRelic::Agent.set_error_group_callback :
proc = proc { |hash| "Access" if hash[:'http.statusCode'] == 401 }NewRelic::Agent.set_error_group_callback(proc)Dans l'exemple illustré, un processus de rappel est créé qui acceptera un hacher comme seul argument, puis renverra la chaîne « Access » pour le nom du groupe d'erreurs souhaité si le hacher contient une clé de code d'état HTTP avec une valeur de 401.
Le processus de rappel est censé recevoir exactement un argument d'entrée, un hacher. Le hacheur contient les éléments suivants :
Key | Value |
|---|---|
| L'instance de classe d'erreur Ruby. Offres |
| Tout attribut personnalisé pour la transaction en cours |
| L'URI de la requête actuelle si disponible |
| Le code d'état HTTP (200, 404, etc.) s'il est disponible |
| La méthode HTTP (GET, PUT, etc.) si disponible |
| Que l'erreur était attendue (vrai) ou non (faux) |
| Les options que Hacher a transmises à |
La procédure de rappel est censée renvoyer une chaîne représentant le nom du groupe d'erreurs souhaité s'il peut être déterminé. Si la procédure renvoie une chaîne nil ou vide (''), l'erreur recevra une logique de regroupement côté serveur.
Suivi des utilisateurs : associer un identifiant utilisateur à chaque transaction et erreur
Vous pouvez maintenant voir le nombre d'utilisateurs impactés par un groupe d'erreurs.
Les transactions et les erreurs peuvent être associées à un identifiant d'utilisateur si celui-ci est connu de l'agent Ruby New Relic. Utilisez l'API Ruby de l'agent NewRelic::Agent.set_user_id pour fournir à l'agent un ID utilisateur.
Cet appel d'API nécessite un seul argument d'une chaîne représentant un identifiant unique pour un utilisateur final. Cette chaîne peut être un UUID, un identifiant de base de données ou similaire. L'appel d'API doit être effectué au moins une fois par transaction pour informer l'agent Ruby New Relic de l'ID d'utilisateur auquel associer la transaction. Ensuite, lorsque l’agent remarque des erreurs pendant la durée de vie de la transaction, les erreurs porteront un attribut d’agent enduser.id qui contient la valeur de l’ID utilisateur.
Étant donné que l’API est destinée à être appelée chaque fois qu’un nouvel ID utilisateur entre dans le champ d’application, elle sera idéalement appelée via un middleware prenant en compte la création de session utilisateur. Une fois que l'agent Ruby New Relic a pris connaissance de l'ID utilisateur, il fournira l'attribut d'agent enduser.id sur la transaction en cours ainsi que sur toutes les erreurs constatées pendant la durée de vie de la transaction en cours.
Suivi des versions : utilisez les métadonnées pour voir quelle version a produit une erreur
La boîte de réception des erreurs suivra automatiquement les versions de votre logiciel qui génèrent des erreurs. Toutes les données de version seront également affichées dans CodeStream.
Définissez l’une des variables d’environnement suivantes pour vous aider à identifier les versions de votre logiciel qui génèrent des erreurs.
NEW_RELIC_METADATA_SERVICE_VERSIONajoute l'attributtags.service.versionsur l'événement d'erreur data contenant la version de votre code qui est déclenchée, souvent une version sémantique telle que1.2.3, mais pas toujours.NEW_RELIC_METADATA_RELEASE_TAGajoute l'attributtags.releaseTagsur les données d'événement contenant la tag de sortie (telle quev0.1.209ourelease-209).NEW_RELIC_METADATA_COMMITajoute l'attributtags.commitsur les données d'événement contenant le commit sha. Vous pouvez utiliser le sha entier ou seulement les sept premiers caractères (par exemple,734713b).