Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.

Présentation

Le SDK Browser collecte les erreurs frontend, y compris le message d’erreur et la trace de pile lorsqu’ils sont disponibles. Pour le tri et la gestion de ces erreurs dans le produit Error Tracking, consultez Browser Error Tracking.

Lorsque le SDK Browser collecte une erreur :

  • L’erreur est capturée en tant qu’événement d’erreur dans RUM.
  • Les filtres de rétention qui ciblent les sessions contenant un événement d’erreur conservent la session actuelle.
  • Les métriques RUM rum.measure.error, rum.measure.session.error et rum.measure.view.error_free sont mises à jour, que la session soit conservée ou non.
  • L’erreur est capturée dans Error Tracking.

Les règles Error Tracking ne s’appliquent pas aux événements d’erreur, et RUM enregistre toujours les événements d’erreur qui correspondent aux problèmes ignorés et exclus dans Error Tracking. Pour empêcher l’enregistrement d’erreurs en tant qu’événements d’erreur, vous devez les rejeter avant qu’elles ne soient envoyées à Datadog à l’aide du rappel beforeSend.

Sources d’erreur

Les erreurs frontend proviennent de plusieurs sources différentes :

  • agent : De l’exécution du SDK
  • console : Des appels d’API console.error()
  • custom : Envoyé avec l’API addError
  • report : De l’API ReportingObserver
  • source : Des exceptions non gérées ou des rejets de promesse non gérés dans le code source

Attributs d’erreur

Pour plus d’informations sur les attributs par défaut de tous les types d’événements, consultez Données collectées. Pour plus d’informations sur la configuration de l’échantillonnage ou du contexte global, consultez Modification des données et du contexte.

AttributTypeDescription
error.sourcechaîneL’origine de l’erreur (par exemple, console).
error.typechaîneLe type d’erreur (ou code d’erreur dans certains cas).
error.messagechaîneUn message concis, lisible par l’homme et sur une seule ligne expliquant l’événement.
error.stackchaîneLa trace de pile ou des informations complémentaires sur l’erreur.
error.causesArrayUne liste facultative d’erreurs fournissant un contexte supplémentaire. Cet attribut est utilisé pour afficher les erreurs séparément et améliorer le formatage. Pour plus d’informations, consultez la documentation MDN.

Erreurs source

Les erreurs source incluent des informations au niveau du code concernant l’erreur. Plus d’informations sur les différents types d’erreurs sont disponibles dans la documentation MDN.

AttributTypeDescription
error.typechaîneLe type d’erreur (ou code d’erreur dans certains cas).

Configurer le suivi des erreurs WebAssembly

Pour suivre les erreurs WebAssembly (WASM), installez le plugin WASM du SDK Browser. Utilisez la même version pour le plugin et le SDK RUM Browser :

npm install --save-exact \
  @datadog/browser-rum@<VERSION> \
  @datadog/browser-plugin-wasm@<VERSION>

Enregistrez le plugin lors de l’initialisation de RUM :

import { makeWasmPlugin } from '@datadog/browser-plugin-wasm';
import { datadogRum } from '@datadog/browser-rum';

datadogRum.init({
  // ...
  plugins: [makeWasmPlugin()],
});

Initialisez RUM avant de charger tout module WASM. Le plugin observe les modules créés avec les API WebAssembly du navigateur et ajoute leurs URL et build IDs aux erreurs contenant une trace de pile WASM. Cela permet à Datadog de sélectionner le bon ID de build lorsqu’une application charge plusieurs modules.

Les erreurs non gérées sont collectées automatiquement. Pour signaler une erreur WASM gérée, passez l’objet Error à addError().

Ensuite, téléchargez les symboles WebAssembly pour symboliser les erreurs.

Collecter les erreurs manuellement

Surveillez les exceptions gérées, les rejets de promesses gérés et d’autres erreurs non suivies automatiquement par le SDK Browser avec l’API addError() :

addError(
    error: unknown,
    context?: Context
);

Remarque : Error Tracking traite les erreurs envoyées avec la source définie sur custom, source, report ou console, et contenant une trace de pile. Les erreurs envoyées avec toute autre source (telle que network) ou envoyées depuis des extensions de navigateur ne sont pas traitées par Error Tracking.

import { datadogRum } from '@datadog/browser-rum';

// Send a custom error with context
const error = new Error('Something wrong occurred.');

datadogRum.addError(error, {
    pageStatus: 'beta',
});

// Send a network error
fetch('<SOME_URL>').catch(function(error) {
    datadogRum.addError(error);
})

// Send a handled exception error
try {
    //Some code logic
} catch (error) {
    datadogRum.addError(error);
}
// Send a custom error with context
const error = new Error('Something wrong occurred.');

window.DD_RUM.onReady(function() {
    window.DD_RUM.addError(error, {
        pageStatus: 'beta',
    });
});

// Send a network error
fetch('<SOME_URL>').catch(function(error) {
    window.DD_RUM.onReady(function() {
        window.DD_RUM.addError(error);
    });
})

// Send a handled exception error
try {
    //Some code logic
} catch (error) {
    window.DD_RUM.onReady(function() {
        window.DD_RUM.addError(error);
    })
}
// Send a custom error with context
const error = new Error('Something wrong occurred.');

window.DD_RUM && window.DD_RUM.addError(error, {
    pageStatus: 'beta',
});

// Send a network error
fetch('<SOME_URL>').catch(function(error) {
    window.DD_RUM && window.DD_RUM.addError(error);
})

// Send a handled exception error
try {
    //Some code logic
} catch (error) {
    window.DD_RUM && window.DD_RUM.addError(error);
}

Instrumentation des limites d’erreurs de React

Vous pouvez instrumenter les limites d’erreurs de React 5 pour surveiller les erreurs de rendu React à l’aide de l’API addError() du SDK RUM Browser.

Les erreurs de rendu collectées contiennent une pile de composants, qui est déminifiée comme n’importe quelle autre trace de pile d’erreurs après avoir téléchargé les sourcemaps.

Pour instrumenter les limites d’erreur React à des fins de surveillance, procédez comme suit :

import { datadogRum } from '@datadog/browser-rum';

class ErrorBoundary extends React.Component {
  ...

  componentDidCatch(error, info) {
    const renderingError = new Error(error.message);
    renderingError.name = `ReactRenderingError`;
    renderingError.stack = info.componentStack;
    renderingError.cause = error;

    datadogRum.addError(renderingError);
  }

  ...
}
class ErrorBoundary extends React.Component {
  ...

  componentDidCatch(error, info) {
    const renderingError = new Error(error.message);
    renderingError.name = `ReactRenderingError`;
    renderingError.stack = info.componentStack;
    renderingError.cause = error;

    DD_RUM.onReady(function() {
       DD_RUM.addError(renderingError);
    });
  }

  ...
}
class ErrorBoundary extends React.Component {
  ...

  componentDidCatch(error, info) {
    const renderingError = new Error(error.message);
    renderingError.name = `ReactRenderingError`;
    renderingError.stack = info.componentStack;
    renderingError.cause = error;

     window.DD_RUM &&
       window.DD_RUM.addError(renderingError);

  }

  ...
}

Dépannage

Erreur de script

Pour des raisons de sécurité, les navigateurs masquent les détails des erreurs déclenchées par des scripts inter-origines. Lorsque cela se produit, l’onglet Error Details affiche une erreur avec le message minimal « Script error. »

Exemple d'erreur de script Real User Monitoring

Pour plus d’informations sur les scripts inter-origines et les raisons pour lesquelles les détails sont masqués, consultez CORS et cette note sur les gestionnaires d’événements globaux. Certaines raisons possibles pour cette erreur incluent :

  • Vos fichiers JavaScript sont hébergés sur un nom de host différent (par exemple, example.com inclut des ressources provenant de static.example.com).
  • Votre site web inclut des bibliothèques JavaScript hébergées sur un CDN.
  • Votre site web inclut des bibliothèques JavaScript tierces hébergées sur les serveurs du fournisseur.

Pour gagner en visibilité sur les scripts interorigines, suivez les deux étapes ci-dessous :

  1. Appelez les bibliothèques JavaScript avec crossorigin="anonymous".

    Avec crossorigin="anonymous", la requête pour récupérer le script est effectuée de manière sécurisée. Aucune donnée sensible n’est transmise via des cookies ou une authentification HTTP.

  2. Configurez l’en-tête de réponse HTTP Access-Control-Allow-Origin :

    • Access-Control-Allow-Origin: * pour autoriser toutes les origines à récupérer la ressource.
    • Access-Control-Allow-Origin: example.com pour spécifier une seule origine autorisée. Si le serveur prend en charge des clients provenant de plusieurs origines, il doit renvoyer l’origine pour le client spécifique effectuant la requête.

Pour aller plus loin