乐趣区

关于前端:北斗监控概述之接入篇一

jiezi

作为一位前端开发者，你是否有过这样的困扰。某个用户反馈说，他的页面某个按钮点击不了，或者是基本打不开，然而你本地基本没法复现。因为，你不能通过一直调试的办法，来定位问题和修复问题，所以它十分难以解决。这时，你无妨先理解一下前端异样和性能监控，通过接入监控你能够较为轻松的找到线上问题线索。

接入前端监控零碎，有两种计划，一种是接入内部监控零碎，另外一种是自研。咱们抉择了自研，自研的劣势是你能够依据你的需要来定制。然而，从头开始搭建一个大型的零碎，并不是一个简略的事件。你须要站在产品角度，将前端工程师的需要翻译胜利能，并且要站在架构师的角度来正当分工，解决高并发、实时性的难点，保障系统可能可靠性的运行。如果，你想要学习大型零碎如何设计或者本人想搭建一个前端监控平台，我违心把我的教训和你分享。

  1. 北斗监控之接入篇：自研前端监控的疾速接入办法
  2. 北斗监控之 SDK 篇：重写函数获取更多有用的线上信息
  3. 北斗监控之架构篇：分层架构搞定大数据的难题
  4. 北斗监控之告警篇：实现牢靠、实时、精确告警的办法

北斗监控之接入篇：自研前端监控的疾速接入办法

咱们来看一下一个最简略的监控 SDK 是什么样的。

window.onerror =  (msg, source, line, column, error) => {errorReport({ msg, source, line, column, stack: error.stack})
}

window.addEventListener('unhandledrejection', (event) => {errorReport({ msg: event.reason})
})

在前端利用中，咱们通过 onerror 来监听 js 中一般谬误，通过 unhandledRejection 来监听 Promise 谬误。拿到错误信息后，再通过一个自定义的 errorReport 函数，把收集上来的谬误上报到后端接口就行。

这样咱们就实现了一个最简略的前端监控 SDK。实际上，咱们一个后端接口，收集的必定不止一个前端利用。因而咱们须要我的项目 ID 来对前端利用进行辨别。

罕用的接入形式：推广老本高

以接入 Sentry 监控 SDK 为例。

第一步，你得须要在平台新建一个我的项目，拿到我的项目的 dsn，这个 dsn 实质是一个我的项目 ID。

第二步，你须要通过 script 或 npm 的形式，把 Sentry 的 SDK 引进来。

第三步，你须要初始化 Sentry。

import * as Sentry from "@sentry/browser";

Sentry.init({dsn:"https://examplePublicKey@o0.ingest.sentry.io/0",});

你的利用 publicKey 是 1，他的利用 publicKey 2，Sentry 就是通过 dsn 中的 publicKey 来辨别不同前端利用上报的数据的。所以，任何接 Sentry SDK 的前端利用都加上一个 dsn 的我的项目 ID，能力接 Sentry 监控。

大家可能感觉在业务代码中加个我的项目 ID，再上次线老本也不高啊。然而大家站在监控平台的角度登程，公司外部有上千个我的项目要去推动接入，这看起来一点点的老本乘以一千倍，也会变得十分高。

思路：上线平台向 Web 动静注入

咱们想到的一个思路是，针对 Web 前端利用场景，由上线平台或客户端向前端利用间接注入监控 SDK，省去业务接入的步骤。这样 App 中所有页面不就都可能失去监控了吗？

主动注入的计划很好，但怎么辨别不同的 Web 前端利用？大家也必定想到了，是 url。咱们能够在 errorReport 谬误上报的参数中，对立增加 url 作为我的项目统计标识。

function errorReport(event) {

    // 用 URL 作为我的项目统计标识
    const report = {...event, url: location.href}
  
    fetch('58.com/monitor/js', {body: JSON.stringify(report),
    })
}

以 URL 为维度统计，会引发三个问题

首先是，当初咱们有 url 为维度，也有我的项目 ID 为维度的统计，两种形式要兼容，怎么办呢？

  • 如果一个我的项目，只有一个 URL，那么我的项目 ID 和 URL 理论是等价的。
  • 如果一个我的项目，有两个或三个 URL 呢，怎么办？
  • 但如果一个我的项目的 url 是动态变化的呢，比方文章详情页，url 通常是依据文章 ID 动静生成的。怎么办呢？

计划：兼容多种统计维度

咱们提出了一种兼容多种统计维度的计划。

第一种是，我的项目 ID 计划。业务先到监控平台申请我的项目 ID，再到业务中手动填写我的项目 ID 的计划，这种计划实用于任意我的项目。

第二种是，固定 URL 计划。在后面提到的 Web 场景中，上线平台会帮咱们主动注入监控 SDK，业务又只有一个固定的 URL，就无需入侵业务代码，业务方间接在平台填写 URL 即可把我的项目监控起来。

第三种是，动静 URL 改进的正则计划。正则计划容易造成谬误匹配，比方业务就填了一个 58.com/* 就会把公司的所有 58 域名下的数据都统计到一个我的项目中。改进正则计划能够解决大部分谬误匹配的问题。规定如下：

  1. URL N 个局部的 N，和匹配规定的 N 个局部的 N，要相等。
  2. 能够用 * 匹配 domain 和 path 中的任意局部
  3. * 的数量 < N/2，也就是说一个 URL 有 6 局部，只能用 2 个 *。

尽管兼容多种统计维度的接入计划，是以 Web 为根底进行思考的。但理论开发中，Web 动静注入计划，通过前端推动后端接入比拟难，同时模板场景非常复杂，占比最多的老我的项目较多保护迭代少，整体看来推动老本高收益较小。而 RN 上线平台比拟对立，也没有模板的困扰，计划上会比 Web 简略很多，因而该计划最终会先在 RN 先落地。

小结

本篇章对传统的以我的项目 ID 为维度的接入形式进行了思考，创新性地提出了一种无需入侵业务代码的接入计划，升高了业务方的接入老本，推广起来也会非常容易。该计划会先在 RN 场景下进行落地，业务只需在上线时勾选接入北斗监控，RN 打包平台会主动将北斗 RN SDK 注入到业务中，而后能够间接在监控平台看到 RN 我的项目的监控数据。

退出移动版