共计 3630 个字符，预计需要花费 10 分钟才能阅读完成。
大家好，我是杨胜利。
提到监控零碎，大部分同学首先想到的是后端监控。很显著，比方检测服务器性能，数据库性能，API 的拜访流量，以及各种服务的运行状况等等，都与后端非亲非故。而前端更多承当的是 UI 展示的角色，次要关注页面怎么排版设计，如同没什么须要监测的中央，因而始终以来都没有波及到监控的概念。
于是呢大家就统一认为：只有后端稳固可控，利用就是稳固可控的，可理论状况真的是这样吗？
近年来，前端倒退日益迅猛，得益于 JavaScript 的继续进化和浏览器性能的一直加强，前端能做到的事件越来越多，相应的前端利用的复杂度也越来越高。以前咱们压根不会遇到的问题，当初蹭蹭蹭的一股脑都冒出来了。
举个例子，小明是个前端程序员，有一天用户反馈某页面某按钮点了没有反馈。小明立即找到那个按钮，微微一点，咦？失常的呀。而后小明又用了几个不同的账号测试，仍然是失常的。这下可把小明难倒了。
怎么办？我置信全天下的前端程序员们遇到奇怪问题的反馈是一样的。小明这样通知用户：可能是浏览器缓存问题，不行强制刷新一下，或者退出登录试试？ 用户依照小明的倡议操作一番，果然见效！于是给小明发来了一连串的“感激 🙏”。小明难堪一笑，连忙回复“小意思”。
过了两天，又有一个用户反馈了同样的问题。小明又祭出了下面的万能解决大法，仍然见效。可是问题真的解决了吗？没有啊！然而小明尝试过很多遍都无奈复现异样，可能起因有很多，比方：
- 数据问题，可能取不到某个属性
- 前端问题，JS 代码执行异样
- 接口问题，可能接口无响应，或没有返回预期的值
然而失常状况下是没有问题的，小明屡次测试也都失常，肯定是在某种特定场景下才会呈现这个问题，然而咱们无奈判断，捕获不到。
像这类 Bug 埋伏在咱们的零碎中，好像地雷一样，指不定什么时候就会爆。最难堪的是即使它爆了咱们也很难发现，这就导致咱们的“排雷口头”困难重重。
某个阳光明媚的下午，小明坐在马桶上思考人生。忽然脑海中一道灵光闪过，小明想到：“如果在用户触发异样的那一刻，零碎能主动获取到异样的数据并保存起来，而后在后盾的某个中央能看到这些数据，我不就能够立即找到谬误起因了吗？”
小明一拍大腿，对呀！我怎么没有早点想到呢？这样的话，只有产生异样咱们就能主动捕捉到异样数据，如果再遇到线上报错，咱们不须要用户反馈，本人就能够发现，而且能马上定位谬误起因，这不是两全其美？
我置信许多前端前辈们也已经被上述的问题所困扰，而后也像小明一样，缓缓的有了这个思路：“将报错时的异样数据存下来供后续排查”。在这个思路一直实际的过程中，逐步演变成了明天的前端监控。
当然了，明天的前端监控并不仅仅是监控异样数据，任何有利于产品剖析的数据都能够退出监控。所以我认为前端监控，就是指 采集用户应用零碎过程中产生的要害数据，存储到数据库，后续能够查找和剖析，这样的整套实现就被称为前端监控零碎。
前端监控具体能解决什么问题？
下面用一个例子推导出前端监控呈现的背景，粗略的说了下它如何追踪线上报错问题，大家应该初步理解了前端监控的意义。当初咱们把眼光聚焦在 我的项目 上，再具体探索一下它具体能解决哪些问题。
异样报错问题
首先就是异样报错的问题。就如例子中的场景一样，线上产生异样，有时候咱们难以复现，甚至如果没有用户反馈，咱们都不晓得有这个问题，这样就给用户传递了一种咱们的产品很不稳固的感觉。因而前端监控是线上产品稳固和异样及时反馈的十分要害的保障。
当然了，除了前端的异样，咱们同样能够捕捉 接口异样。有的时候前端程序员们自嘲本人是“背锅侠”，产品，测试，用户，遇到问题首先找前端，不论是不是前端的问题，前端先顶，再花工夫定位谬误。有的时候领导脾气不好，上来先劈头盖脸一顿骂，低微前端也不敢谈话，因为啥问题得排查后才分明，后果排查完后是接口的问题，白挨了一顿骂，心里就十分不爽。
然而如果有了前端监控，咱们就能马上拿到异样产生时的错误信息，页面，地址，参数等，什么问题一查便知。下一次遇到线上事变，前端就能够慌慌张张主观公正的说这是哪一方的问题。如果遇到甩锅行为，前端也能怯懦说不，毕竟我证据在手，岂容你说吼就吼？
性能检测问题
追踪异样是前端监控最实用的中央，但不光如此，性能监控 也是十分要害的局部。
当下的前端工程体量很大，如果代码品质不高，或者我的项目架构设计不合理，很容易遇到性能问题。性能问题比方首屏加载工夫，页面是否卡顿，白屏，资源重复申请等，能够通过数据采集，比方计算渲染工夫，申请接口数量，申请资源总量等，对某个页面进行监控，及时发现性能问题。
那么除了能够“解决问题”，前端监控还有哪些价值？
经营反馈工具
其实前端监控除了能够帮忙程序员一直优化和欠缺利用，对产品和经营同学有同样不可或缺的作用。具体来说就是通过“埋点监控”来收集用户的行为数据，则能够对线上产品的应用状况作出统计分析，比方整体的 PV/UV，某个性能的访问量，拜访时段，点击率等等数据。这些数据能够帮忙产品和经营理解理论状况，进而改良产品性能。
这些行为数据的收集，能够十分精准的描绘出某个性能或者某个人的理论应用状况。当然采集的数据量也要比异样数据大的多。相比来说，异样监控是只有产生异样才会收集数据，而行为数据则是，只有用户应用咱们的产品，与产品产生交互，实践上这些数据都要收集起来。
当然监控是多方面的，收集哪些数据视状况而定。总之你想理解产品的任何状况，都能够通过 设计采集规定 而后收集数据来实现，这方面是非常灵活的，并不仅仅限于大家熟知的那几个指标。
为什么要抉择自研？
前端监控倒退到当初，必然会有成熟的第三方平台。目前国内最罕用的有三个：
- sentry
- webfunny
- fundebug
首先 sentry 和 fundebug 这两个平台是付费的，而且你的数据越多费用越高，相当于是数据托管平台。webfunny 尽管能够私有化部署，然而它的性能是固定的，没法改代码，这就是它的毛病：不够灵便，无奈定制性能。
所以目前尽管市面上曾经有成熟的监控零碎，但仍然有很多团队抉择自研。一是数据能够保留在本人的服务器上，不必另外花钱；二是灵活性强，能够自定义性能，比方你能够在触发异样时，接入本人的钉钉或企业微信音讯推送，这就须要你的监控零碎灵活性很高。
还有咱们下面说的，自定义采集规定。我认为这个是最重要的起因。不同规定采集到的数据不一样，因而第三方规范的采集规定可能并不合乎你公司的需要。比方有的公司须要获取设施标识作为惟一 ID，有的公司却须要用户标识。这是由业务决定的，每个公司都不一样。
我司前端组就是自研前端监控平台。劣势就是能够自定义本人的采集规定，设计本人的数据库存储字段，数据都保留在本人的平台，灵活性和可靠性都十分高，能满足本人的多样性需要。
自研前端监控的技术栈
先上论断，我司的前端监控是前端组本人搞的，所以技术栈是 React + Node.js + MongoDB。
这是一个比拟惯例的技术计划，前端本人搞嘛，所以技术栈都以 JS 为主。同时这也是前端比拟能推敲明确的货色，算是一个规范计划吧。
其中，Node.js 局部咱们应用 express 框架写接口，接口总体分两大类，就是 写入 和 查问统计，作用呢就是前端采集到数据之后，要通过调用接口存储。之后在监控面版上，也要通过接口将数据查问展示进去。
接口的背地就是 MongoDB 数据库，作用就是存储咱们采集到的数据。为什么抉择 MongoDB 呢？最次要的起因就是它的写入性能十分高，写入速度十分快。下面咱们说，监控零碎在采集行为数据的时候，写入十分频繁，那么对写入性能的要求就十分高，反观查问反而要求不那么高。
这里也有比拟难啃的点，就是采集到大量的数据之后，咱们须要各个维度的统计分析。比方：
- 某个时间段用户的拜访次数和拜访时长排行
- 某个时间段页面的拜访频率和停留时间排行
- 某个时间段接口报错的次数以及占比统计
这些比较复杂的查问统计，次要用到 MongoDB 的聚合查问。前端写个根本的分组统计还行，这类简单查问咱们就顾此失彼了。怎么办呢？咱们用很长一段时间啃掉了 MongoDB 聚合查问的所有文档，依照需要一个一个找函数，看哪个能实现，简直把所有聚合函数都翻了一遍。
接口做完，最初用 React 实现一个治理后盾，将数据以图表，表格的模式展现进去，就能够实时看到线上产品的应用状况了。
当然还有一步，就是写一个对接钉钉或企业微信的告诉接口，在触发异样的时候发动告诉，让咱们能及时晓得异常情况。咱们的告诉是这样：
这个信息就能比拟全面的看进去是哪里出了问题，如果看更具体的谬误再去异样面板去找：
总之首先对接口异样全面监控，确认数据没问题之后咱们再前端去排查，效率进步了，锅也少背了，这不是两败俱伤吗？
最初咱们自研的这个小零碎在产品上线后施展了很大的作用，受到了老板的褒扬，这样让咱们受到了鼓励，持续欠缺它～
更多资源
本文起源公众号 程序员胜利。作者杨胜利，专一于前端工程与架构的分享，关注我查看更多硬核常识。
本文的任何问题和倡议，都欢送与我沟通，感激浏览 🙏
