Tous les produits
Search
Centre de documentation

Application Real-Time Monitoring Service:Diagnostiquer les erreurs JS à l'aide de la surveillance du navigateur ARMS

Dernière mise à jour :Aug 26, 2026

Le débogage des erreurs JavaScript en production est complexe : le code est minifié et chaque utilisateur dispose d'un appareil, d'un navigateur et de conditions réseau uniques. La plupart des solutions de surveillance du navigateur s'appuient sur l'objet *PerformanceTiming*, qui ne capture que le temps de chargement complet de la page et exclut les temps de chargement des ressources statiques, ce qui rend difficile l'identification des goulots d'étranglement en matière de performances. Browser Monitoring dans Application Real-Time Monitoring Service (ARMS) combine la prise en charge des source maps avec le suivi rétroactif du comportement des utilisateurs. Cela vous permet de faire correspondre les traces de pile minifiées au code source et de rejouer les actions exactes de l'utilisateur ayant déclenché une erreur.

Prérequis

Avant de commencer, assurez-vous d'avoir :

Fonctionnement des source maps

Une source map est un fichier JSON qui établit une correspondance entre les positions dans le code minifié et les positions correspondantes dans votre code source original. Elle utilise l'encodage VLQ pour stocker les données de localisation de manière compacte. Grâce à une source map, Browser Monitoring traduit une erreur située à la « ligne 1, colonne 79585 » en un fichier, une ligne et une colonne précis dans votre code source.

Flux de travail de diagnostic

Le flux de travail suivant décrit le processus de bout en bout : identifier les tendances des erreurs, faire correspondre les traces de pile minifiées au code source, puis rejouer les actions de l'utilisateur ayant déclenché l'erreur.

Étape 1 : Consulter la vue d'ensemble des erreurs

  1. Connectez-vous à la console ARMS.

  2. Dans le volet de navigation de gauche, choisissez Browser Monitoring > Browser Monitoring.

  3. Sur la page Browser Monitoring, sélectionnez une région dans la barre de navigation supérieure et cliquez sur le nom de l'application que vous souhaitez gérer.

  4. Dans le volet de navigation de gauche, cliquez sur JS Error Diagnosis.

JS Error Diagnosis

Sur cette page :

  • La section Error Overview affiche le nombre total d'erreurs, le taux d'erreurs JS ainsi que le nombre et le pourcentage d'utilisateurs affectés.

  • Le graphique en courbes illustre l'évolution des erreurs dans le temps.

  • L'onglet Frequent Errors répertorie les erreurs les plus fréquentes.

  • Les onglets Page Ranked by Error Rate et Error View affichent la répartition des erreurs par page.

Étape 2 : Analyser une erreur spécifique

Deux points d'entrée sont disponibles :

  • Dans l'onglet Frequent Errors, cliquez sur Diagnose à côté de l'erreur cible.

  • Dans le graphique en courbes, cliquez sur un point de données à un moment donné pour ouvrir la boîte de dialogue Exception Insight.

L'exemple suivant utilise l'approche par graphique en courbes :

  1. Sur le graphique en courbes, identifiez un point où le taux d'erreur augmente brusquement. Placez le curseur sur le point d'inflexion jusqu'à ce qu'il se transforme en icône de main, puis cliquez dessus. La boîte de dialogue Exception Insight s'affiche. Pour plus d'informations, consultez la rubrique Afficher les informations sur les exceptions.

    Exception Insight

  2. Cliquez sur l'onglet Frequent Errors Top 5, sélectionnez une erreur, puis cliquez sur Diagnose dans la colonne Operation. L'onglet Error Detail s'affiche.

Étape 3 : Examiner les détails de l'erreur

La page de détail des erreurs fournit le contexte suivant :

Champ Description
Heure de première occurrence Moment où l'erreur a été enregistrée pour la première fois
Version lors de la première occurrence Version de l'application lorsque l'erreur est apparue pour la première fois (facultatif)
Nom et type de l'erreur Nom et classification de l'erreur JavaScript
Heure d'occurrence Moment où cette instance d'erreur s'est produite
Appareil, système d'exploitation, navigateur Environnement client dans lequel l'erreur s'est produite
Adresse IP, région Emplacement réseau de l'utilisateur
Type de connexion Connexion réseau (Wi-Fi, 4G, etc.)
URL de l'erreur URL de la page où l'erreur a été déclenchée
Version de l'application Version déployée de l'application
Fichier, ligne, colonne Position dans le fichier minifié

Exemple : La capture d'écran suivante montre une erreur provenant d'un module de carte sur un tableau de bord en temps réel. Le module a signalé des données non valides lors d'une mise à jour, et la trace de pile pointe vers la ligne 1, colonne 79585 dans le bundle minifié.

Error Details

« Ligne 1, colonne 79585 » n'est pas exploitable car le code de production est minifié. L'étape suivante consiste à faire correspondre cette position à votre code source.

Étape 4 : Faire correspondre l'erreur au code source

Les numéros de ligne et de colonne dans la trace de pile pointent vers du code minifié, et non vers vos fichiers sources. Appliquez une source map pour résoudre l'emplacement original de l'erreur.

  1. Dans la section Stack Info, cliquez sur l'icône expand icon à gauche d'un frame de pile pour le développer, puis cliquez sur Choose Sourcemap.

  2. Dans la boîte de dialogue Sourcemap File, sélectionnez un fichier source map existant ou téléchargez-en un nouveau, puis cliquez sur OK.

    Remarque

    Vous pouvez télécharger jusqu'à cinq fichiers à la fois.

    Sourcemap File dialog

  3. Après avoir appliqué la source map, Browser Monitoring met en surbrillance en rouge l'emplacement original de l'erreur dans la section Source Code, en affichant le fichier et la ligne exacts où l'erreur s'est produite. appliquez des source maps à chaque frame de la pile d'erreurs pour retracer la chaîne d'appels complète.

Étape 5 : Reproduire l'erreur grâce au suivi rétroactif du comportement des utilisateurs

Le mappage des source maps révèle l'erreur s'est produite, mais pas toujours pourquoi. Dans l'exemple du module de carte, le mappage du code source montre que des données non valides ont provoqué l'erreur lors de la création du composant. Toutefois, le code source inclut déjà des vérifications de nullité et une tolérance aux pannes pour ces données. Pour comprendre pourquoi les données non valides sont apparues, examinez ce qui s'est passé immédiatement avant l'erreur.

Browser Monitoring enregistre le comportement des utilisateurs sous forme de trace chronologique de nœuds d'événements :

  • Chargement de la page

  • Modifications de route

  • Clics sur la page

  • Requêtes API

  • Sortie de console

Consultez cette trace pour rejouer la séquence d'actions ayant conduit à l'erreur.

Exemple : La trace de comportement utilisateur suivante montre qu'une requête API a eu lieu juste avant l'erreur. L'appel API demandait une mise à jour en temps réel pour le module de carte, mais la réponse a renvoyé ConsoleNeedLogin au lieu de données de carte valides. Cela indique que l'utilisateur s'était déconnecté de la page, ce qui constitue la cause profonde des données non valides.

User Behavior Trace

Générer des source maps

Les source maps sont requises pour l'étape 4 du flux de travail de diagnostic. Générez une source map avec votre outil de build, puis téléchargez-la sur la console ARMS.

Pour télécharger un fichier source map, recherchez votre application sur la page Browser Monitoring, puis choisissez More > Settings dans la colonne Actions. Sur la page des paramètres, cliquez sur l'onglet Advance.

Webpack

Dans webpack.config.js, définissez la propriété devtool sur "source-map". Webpack prend en charge 13 valeurs devtool pour différents types de source maps. "source-map" génère un fichier .map complet et distinct, ce qui est recommandé pour le diagnostic des erreurs en production.

const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    devtool: "source-map"
};

Gulp

Utilisez le package gulp-sourcemaps :

var gulp = require('gulp');
var sourcemaps = require('gulp-sourcemaps');

gulp.task('javascript', function() {
    gulp.src('src/**/*.js')
        .pipe(sourcemaps.init())
        .pipe(sourcemaps.write('../sourcemaps'))
        .pipe(gulp.dest('dist'));
});

Grunt

Avec grunt-contrib-uglify uniquement :

grunt.initConfig({
    uglify: {
        options: {
            sourceMap: true
        }
    }
});

Avec grunt-usemin (qui appelle grunt-contrib-concat et grunt-contrib-uglify) :

grunt.initConfig({
    concat: {
        options: {
            sourceMap: true
        }
    },
    uglify: {
        options: {
            sourceMap: true,
            sourceMapIn: function(uglifySource) {
                return uglifySource + '.map';
            },
        }
    }
});

Avec grunt-jsmin-sourcemap :

module.exports = function(grunt) {
    grunt.loadNpmTasks('grunt-jsmin-sourcemap');
    grunt.initConfig({
        'jsmin-sourcemap': {
            all: {
                src: ['scripts/script.js'],
                dest: 'scripts/script.jsmin-grunt.js',
                destMap: 'scripts/script.jsmin-grunt.js.map'
            }
        }
    });
    grunt.registerTask('default', 'jsmin-sourcemap');
};

Angular CLI

ng build --prod --source-map --vendor-source-map

UglifyJS2

UglifyJS2 est un outil CLI. Pour plus d'options, consultez Options de source map CLI.

uglifyjs app.js -o app.min.js --source-map app.min.js.map

SystemJS

Utilisez SystemJS Builder :

builder.bundle('app.js', 'app-outfile.js', {
    minify: true,
    sourceMaps: true
});