编辑应用 -> 错误栈配置

需要看到解析后的前端错误堆栈信息需要满足以下条件:

  • 探针版本不低于2.0.4(必须)
  • 配置sourcemap路径(上传路径):{product_code}/{app_code}
  • 当存在多层路径时,需要通过虚拟路径正则进行匹配(配置错误不影响数据采集,只是无法解析错误堆栈)
  • 上传sourcemap(如不上传无法看到错误在源码中的位置)

虚拟目录正则的工作过程可简述为以下步骤

  • 虚拟目录正则配置:^saas
  • 错误堆栈中的文件路径:saas/static/js/xxxx.js(/saas为部署地址的路径)
  • 经过虚拟目录正则处理后:static/js/xxxx.js
  • 拼接sourcemap目录配置(以默认的路径为例):{product_code}/{app_code}/static/js/xxxx.js'}

使用工具上传sourcemap

天眼提供了sourcemap上传的工具,分为webpack插件与node脚本,配置参数如下

配置 字段类型 说明 是否必填 默认值
app_key string 项目唯一标识
product_code string product_code
app_code string app_code
is_delete_source_map boolean 是否在输出阶段删除.js.map和.css.map文件 true
timeout number 单个文件上传超时时间,默认值300000,5分钟 300000
sts_url string STS上传权限获取接口 -

找到产品编码、应用编码和APP KEY

在产品管理中,可以在下图的位置找到产品编码和应用编码

在修改应用的弹窗中,可以找到APP KEY(如果点击了刷新按钮,则会生成一个新的APP KEY,需要将原有的webpack插件或NODE脚本配置中的APP KEY修改为最新)

基于webpack使用(FAST SourceMap Upload Webpack Plugin)

fast-sourcemap-upload-webpack-plugin是基于webpack4开发的webpack插件,为天眼探针定位上报异常在源代码中的确切位置提供source文件和map文件

使用前必须开启sourcemap文件生成配置,在输出目录中会搜索所有的.js、.js.map并上传,并根据插件配置删除.js.map和.css.map

在开发环境不要使用该插件,否则会导致因上传文件延长热加载时间

npm install fast-sourcemap-upload-webpack-plugin -D

在webpack中

// 开启sourcemap
devtool: 'hidden-source-map',
// 配置sourcemap文件上传插件
plugins: [
  new FastSourcemapUploadWebpackPlugin({
    app_key: '{your app_key}',
    product_code: '{your product_code}',
    app_code: '{your app_code}',
    is_delete_source_map: true
  })
]

在umi中 config.js

import FastSourcemapUploadWebpackPlugin from 'fast-sourcemap-upload-webpack-plugin';

export default {
  // 开启sourcemap
  devtool: 'hidden-source-map',
  chainWebpack: config => {
    config
    // 使用fast-sourcemap-upload-webpack-plugin插件
    .plugin('fast-sourcemap-upload-webpack-plugin') 
    .use(new FastSourcemapUploadWebpackPlugin({
      app_key: '{your app_key}',
      product_code: '{your product_code}',
      app_code: '{your app_code}',
      is_delete_source_map: true
    }))
  },
  plugins: [
    ['umi-plugin-react', {}]
  ]
}

在node环境直接使用(FAST SourceMap Upload)

fast-sourcemap-upload根据用户配置的文件目录,自动递归搜索配置目录下的source文件和.map文件,并根据文件名与oss仓库文件做比对,实现增量上传源文件与map文件

npm install fast-sourcemap-upload -D

创建一个js文件 nodeUpload.js

const nodePlugin = require('fast-sourcemap-upload');
const path = require('path')
nodePlugin({
  app_key: 'your app——key',
  product_code: 'your product_code',
  app_code: 'your app_code',
  upload_url: path.resolve(__dirname, 'your dir_path'),
  is_delete_source_map: true,
})

项目打包后,在终端执行命令行

node nodeUpload

生成与上传sourcemap的注意事项

1、配置devtool生成sourcemap文件时,如果您的项目需要保留sourcemap文件,那么推荐使用 'source-map' 模式,该模式为 bundle 添加了一个引用注释,以便开发工具知道在哪里可以找到它。如果您的项目不需要保留生产的sourcemap文件,推荐使用 'hidden-source-map' 模式,与source-map 相同,但不会为 bundle 添加引用注释

2、如果您的项目将css、less、scss文件打包入您的js文件时,请在相关loader中关闭您css、less、scss相关文件的sourcemap生成配置。以防止生成的map文件一并打包入您的js文件中,导致js文件大小超过预期,例如:

{
  loader: 'style-loader',
  options: {
    sourceMap: false
  }
}

3、由于node对进程的内存分配有默认设置,32位系统 node默认分配内存 0.7g左右,64位系统默认分配内存1.4g左右, 如果项目复杂,在开启souremap生成选项时,打包的时候可能出现内存不足导致打包失败的情况,例如:

<--- Last few GCs --->

[70041:0x103800000]   112100 ms: Mark-sweep 1049.8 (1273.7) -> 1049.7 (1214.2) MB, 427.1 / 0.0 ms  (average mu = 0.618, current mu = 0.000) last resort GC in old space requested
[70041:0x103800000]   112510 ms: Mark-sweep 1049.7 (1214.2) -> 1049.7 (1192.2) MB, 410.3 / 0.0 ms  (average mu = 0.447, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x36295d35be3d]
Security context: 0x0280a0d9e6e1 <JSObject>
    1: byteLength(aka byteLength) [0x280057866f1] [buffer.js:531] [bytecode=0x280f3e290c1 offset=204](this=0x0280cf7826f1 <undefined>,string=0x028037c8a291 <Very long string[190258200]>,encoding=0x0280a0dbd819 <String[4]: utf8>)
    2: arguments adaptor frame: 3->2
    3: fromString(aka fromString) [0x2800579d2d9] [buffer.js:342] [bytecode=0x280f3e278e1 offs...

解决方案是在配置打包命令时,修改node进程占用内存的大小 --max-old-space-size,例如:

// package.json中

"scripts": {
  "build": " node --max-old-space-size=4096 ./scripts/build.js",
}

4、使用vue-cli构建sourcemap文件,出现chunk-vendor.js.xxx.map解析不正确.

这个可能是vue-cli构建缓存导致的,vue-cli-service build 命令时,会在node_module 下的.cache文件中缓存构建信息,切换sourcemap生成规则时,对于chunk-vendor.js.map的生成存在bug,该文件的生成会直接从缓存中读取数据,而其他的文件则重新生成了,清除掉node_module下的缓存文件.cache文件夹后,可以生成正确的chunk-vendor.js.map文件,这是vue-cli的一个bug.

发生场景就是: 使用vue-cli,先使用一种sourcemap生成规则,生成了一次文件,在次构建时,使用了另外一种sourcemap构建模式,由于源文件内容没有发生变化,文件名的hash值不会变化,导致vendor读取的是缓存数据,生成的map文件使用的是缓存信息,而其它map文件不会出现该问题,导致chunk-vendor.js.xxxx.map在堆栈解析时发生异常.

解决方案: 如果存在该问题,可以尝试删除node_module下的.cache文件夹,再重新进行一次构建上传.

数据查看入口

应用异常 -> 前端错误 -> 错误页面列表 - 详情 -> 错误列表 -> 错误详情

results matching ""

    No results matching ""