ブラウザ監視を使用して JS エラーを診断する - Application Real-Time Monitoring Service

JavaScript（JS）エラーはアプリケーションの品質に直接影響します。そのため、JS エラーを特定して診断する必要があります。Application Real-Time Monitoring Service（ARMS）のブラウザ監視サブサービスは、JS エラー診断機能を提供し、JS エラーを正確に特定し、効率的に診断するのに役立ちます。

前提条件

ソースマップはビルダーで生成されます。ソースマップファイルをアップロードするには、ARMS コンソールにログインします。[ブラウザ監視] ページでアプリケーションを見つけ、[アクション] 列の [その他] > [設定] を選択します。表示されるページで、[詳細設定] タブをクリックします。

背景情報

実際には、JS エラーの診断中に次の問題が発生する可能性があります。

エラーを再現できない。
たとえば、ユーザー A がページにアクセスすると、ページはユーザー A のブラウザに読み込まれます。ページの読み込みにかかる時間は、リージョン、ネットワーク、ブラウザ、キャリアなどの要因の影響を受けます。そのため、ユーザー A がページにアクセスしたときに発生したエラーを再現することはできません。
監視データがないため、エラー原因を特定できない。
ほとんどのブラウザ監視プロジェクトは、PerformanceTiming オブジェクトを使用してページ全体の読み込み時間を取得しますが、静的リソースの読み込み時間は除外されます。そのため、パフォーマンスボトルネックを特定できません。

ブラウザ監視では、ソースマップを使用してコード内のエラーを特定し、ユーザー行動のバックトラッキング機能を使用して JS エラーを再現できます。これにより、開発者はソースコード内のエラーをすばやく特定し、障害のあるコードブロックを見つけることができます。

ソースマップとは

ソースマップは、変換前と変換後のソースコード間のマッピングを提供するファイルです。開発者はソースマップを使用して、障害のあるコードブロックを特定できます。実際には、ソースマップは VLQ エンコーディングと特定のルールを使用して位置情報を格納する JSON キーと値のペアです。つまり、ソースマップは前処理コードと後処理コードの間にブリッジを構築します。

ビルダーを使用してソースマップを生成する

Webpack

webpack.config.js 構成ファイルで、devtool 属性を設定してソースマップを生成します。

const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    devtool: "source-map" // DevTools には 13 個の値があり、それぞれ異なるタイプのソースマップに対応しています。devtool 属性を source-map に設定することをお勧めします。
};

Gulp

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

grunt-contrib-uglify のみを使用してソースコードを圧縮するには、次のコードを実行します。

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

grunt-usemin は、grunt-contrib-concat と grunt-contrib-uglify を呼び出してソースコードを圧縮します。 grunt-usemin を使用してソースコードを圧縮するには、次のコードを実行します。

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

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');
};

AngularJS

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

UglifyJS2
UglifyJS2 は CLI ツールです。UglifyJS2 を使用するには、次のコードを実行します。詳細については、「CLI ソースマップオプション」をご参照ください。
```
$ uglifyjs app.js -o app.min.js --source-map app.min.js.map
    
```

SystemJS

SystemJS builder を使用するには、次のコードを実行します。

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

手順 1：ARMS エージェントをインストールする

アプリケーションを包括的に監視するには、アプリケーションに ARMS エージェントをインストールする必要があります。ビジネス要件に基づいて、ARMS エージェントをインストールする方法を選択します。エージェントのインストール方法の詳細については、「Web アプリケーションの監視」をご参照ください。

手順 2：エラーの概要を表示する

ARMS コンソールにログインします。左側のナビゲーションウィンドウで、[ブラウザ監視] > [ブラウザ監視] を選択します。
[ブラウザ監視] ページで、上部のナビゲーションバーでリージョンを選択し、管理するアプリケーションの名前をクリックします。
左側のナビゲーションウィンドウで、[JS エラー診断] をクリックします。
- [エラーの概要] セクションで、エラーの総数、JS エラー率、影響を受けたユーザーの数と割合を表示します。
- 曲線チャートに基づいて JS エラーの傾向を判断します。
- [頻度の高いエラー] タブで、頻度の高いエラーをフィルタリングします。
- [エラー率でランク付けされたページ] タブと [エラービュー] タブのデータに基づいて、JS エラーに関する全体的な情報を分析します。

手順 3：特定のエラーを診断する

JS エラーに関する全体的な情報を分析した後、特定のエラーのトラブルシューティングを行う必要があります。ARMS コンソールで JS エラーを診断するには、次の 2 つの方法を使用できます。

[頻度の高いエラー] タブで、[診断] をクリックして診断ページに移動します。
曲線チャートで特定の時点を選択し、[例外インサイト] ダイアログボックスに移動します。

このトピックでは、2 番目の方法を例として使用します。

曲線チャートの特定の時点のエラー率が急激に増加していることがわかった場合は、ポインタを曲線の転換点に移動します。ポインタが手のアイコンに変わったら、転換点をクリックします。その時点の [例外インサイト] ダイアログボックスが表示されます。詳細については、「例外インサイトを表示する」をご参照ください。
[上位 5 件の頻度の高いエラー] タブをクリックします。このタブでエラーを選択し、エラーの診断[操作] 列のをクリックします。
[エラーの詳細] タブが表示されます。

手順 4：エラーの詳細を表示する

JS エラーの詳細は、最初の発生時刻、最初の発生バージョン（オプション）、エラー名、エラータイプ、発生時点、デバイス、オペレーティングシステム、ブラウザ、IP アドレス、接続タイプ、リージョン、エラー URL、アプリケーションバージョンなどです。詳細には、エラーが発生したファイル、行、列も含まれます。次の図は、エラーの詳細を示す例です。リアルタイムダッシュボードのマップモジュールは、更新中に無効なデータのエラーを報告し、エラーは 1 行目、79585 列目で発生しました。

手順 5：ソースコード内のエラーを特定する

オンラインコードはコンパイル、圧縮、難読化の後では判読できないため、JS エラーの詳細から取得した情報はエラー診断には不十分です。表示された情報では、エラーが 1 行目、79585 列目で発生したことが示されていますが、これはソースコード内の実際のエラーの場所ではありません。この場合、ソースコードマッピングにソースマップを使用する必要があります。

[スタック情報] セクションで、スタックの左側にあるアイコンをクリックして行を展開し、[ソースマップを選択] をクリックします。
[ソースマップファイル] ダイアログボックスで、既存のソースマップファイルを選択するか、新しいソースマップファイルをアップロードし、[OK] をクリックします。
説明
最大 5 つのファイルを同時にアップロードできます。
ブラウザ監視はソースマップを使用して正確なエラーの場所を特定します。選択したソースマップがソースコードのエラーと一致する場合、元のエラーの場所は [ソースコード] セクションで赤色でマークされます。分析後、エラーが発生したファイルとコード行を簡単に特定できます。また、エラースタックの各行のソースコードマッピングにソースマップを使用できます。

手順 6：バックトラックされたユーザーの行動を表示する

ソースコードマッピングは、マップコンポーネントの作成中に無効なデータが読み込まれたためにソースコードエラーが発生したことを示しています。ただし、無効なデータはさまざまな形式で表示される場合があります。ソースコードのデータに対して null 判定とフォールトトレランスが実行されていますが、無効なデータが引き続き発生しています。エラーデータのスナップショットを取得できれば、エラーの原因をより正確に特定できます。ただし、オンサイトデータは通常、グローバル例外キャプチャでは使用できず、ユーザーがエラーとともにデータを報告した場合にのみデータを取得できます。

最良のトラブルシューティング方法は、エラーを再現することです。ブラウザ監視は、ページの読み込み、ルートジャンプ、ページクリック、API リクエスト、コンソール出力など、ページ上のイベントノードをユーザーの行動として定義します。ユーザーの行動は時系列で接続され、行動トレースを形成します。エラー時の行動のバックトラッキングは、開発者がエラーを再現するのに役立ちます。

エラーのユーザー行動のバックトラッキングは、次のユーザー行動のバックトラッキングの図に示すように、エラーが発生する前に API リクエストが行われたことを示しています。この API 操作はマップモジュールのリアルタイム更新をリクエストしましたが、返されたデータは ConsoleNeedLogin です。これは、ユーザーがページからログオフしたことを示しています。これが無効なデータの根本原因です。