首页预览
背景：入职不久，被要求去电销群里解决线上的问题，说都堆了一堆问题了。我一听，这是要重用我啊，于是乎，摩拳擦掌冲进电销群里，准备大干一场。我向上翻了半个小时的聊天记录，隐隐感觉到背后有一股凉意，我转头看了一眼老大，只见他嘴角上扬，向我致以亲切微笑，好像是在说”我相信你能行“，既然这么被信任我，还有什么好说的。 好在我们公司也不是什么小气的主儿，什么监控系统都舍得买，光前端相关的监控系统就有仨（当然现在一个都没有了，因为嫌太贵，啪啪打脸）。正是因为我常游走于这几个监控系统之间，所以隐隐感觉到这些监控都有不能够满足我的需求。并不是说这些监控系统都不好，毕竟他们都是成名公司的产品，而是因为我想拥有一个属于自己的监控系统，我想监控什么就监控什么，就这么简单。
前言：当你开发的项目在线上运行的时候，你能否知道它是否在健康的运行呢？当你的js出现大量报错，你能及时的知道，并快速的修复吗？当你的接口出现大量的错误导致线上错误，你能快速发现并及时甩锅给后端的小伙伴吗？当你的CDN嗝屁了，你能知道是运行商的问题，而不是满头大汗排查你的代码吗？当你线上的用户在app上做了一大堆奇葩的操作，搞成了一个莫名的Bug，你有信心将它复现吗？
如果，你还是一位手无寸铁的前端小白，那我觉得你就太南了，你无法解决以上的任何问题，赶紧去整一个吧，哈哈。 话不多说，看看我们需要做些什么吧。
=================================
Github搜索：webfunny_monitor ，或者访问网站：www.webfunny.cn ; 只需要简单几步，就可以搭建一套属于自己的前端监控系统，试试吧。
=================================
功能分析：
- 1. 用户访问页面的监控与上报功能：
记录用户访问页面的行为；记录用户首次访问页面的加载时间；可以分析用户的PV/UV数据、用户的访问轨迹、统计页面加载耗时、评估用户的网络环境等。
- 2. Js代码执行时异常、自定义异常的监控与上报功能：
javascript代码异常分为执行时异常，自定义异常，第三方异常。我们对其进行分类上报和分析。
- 3. 接口请求（包括成功与失败状态，接口请求耗时）的监控与上报功能：
用户在使用应用的时候，会发生大量的接口请求，接口请求会出现400，500等报错异常，也会出现耗时过长无法获取数据，以及接口参数和接口返回结果，我们都会对其进行上报。
- 4. 静态资源加载日志的监控与上报功能：
说实话，我们已经不止一次遇到CDN报错的问题了，静态资源加载报错是对用户使用体验影响最大的因素，因为会直接导致应用空白而无法使用，这个也是我们需要监控的重点对象。
- 5. 点击事件日志的记录与上报功能：
用户在应用上最直接的交互行为就是点击事件，很多异常都是在点击之后发生，所以需要记录用户的点击行为，才能够更快速地帮助用户解决问题。
- 6. 截屏日志的记录、录屏日志的记录与上报功能
在将以上的方法都排查过后，依然无法找到原因，我们可以使用JavaScript技术对页面进行截屏，甚至，我们可以对用户的页面进行录屏，看到用户是如何使用的，对问题的原因进行查找。
- 7. 用户行为的记录与分析：
线上用户的行为表现多种多样，有些用户在应用中的表现超出预期，我们无法通过整体的统计情况来解决问题，这个时候就需要针对具体的用户进行处理，我们会通过用户的标识信息查看用户在应用整个生命周期中的行为，追踪每一步的具体信息，从而定位出问题所在。
技术工具：
好了，功能分析做完了，我们可是认真的，看看我们需要用到哪些技术和工具来帮我们完成任务。前端监控系统分为三个部分，探针、后端分析服务、数据可视化系统。探针部分使用JavaScript原生代码编写，引入html2canvas, rrweb等插件进行截屏和录屏；后端分析服务采用以nodeJs为基础的koa2框架搭配mysql5.4进行编写；数据可视化系统采用的是react全家桶、webpack、es6等技术进行开发。整套系统采用前后分离的架构设计，功能边界划分清晰，开发起来非常方便。
系统框架简图
流程设计：
- 1. 总流程：
监控系统总流程图
- 2. 日志搜集流程：
日志搜集流程图
探针部署到应用中后，便开始对页面访问日志、JavaScript报错日志、接口请求日志、静态资源加载日志、点击行为日志、截屏录屏日志等进行监听。一旦获取到日志信息，边通过加密手段进行处理，然后将其储存在浏览器本地缓存中。由于用户的日志信息量比较多，所以需要将日志信息积攒到一定数量之后再进行上传。所以，会在浏览器中定时检查本地缓存中日志的数量，达到一定量之后，上传给后台的消息队列。至此，完成了一轮完整的上传操作。
- 3. 日志上报流程：
日志上报流程图
由于用户的行为日志种类比较多，每个用户都有可能在同一时间产生很多的日志信息，一但用户集中访问我们的应用，就会出现并发问题。比如公司发送推文，做活动的时候，都会出现这种情况。为了解决这个并发问题，我们使用消息队列的方法来进行削峰填谷，以缓解对服务器造成的压力。所以前端应用产生的日志会发送给日志上报服务器，上报服务器接收到日志信息后，不会立即存储到数据库中，而是将信息存到消息队列中。与此同时，日志接收服务也会不停的检查消息队列中的消息，一旦检测到消息内容，就会将队列中的消息取出，并存放在mysql数据库中。至此，日志上报流程就完成了。
- 4. 日志查询和分析流程：
日志查询和分析流程图
日志接收服务从消息队列中取出日志信息，并将其分类存入到mysql数据库以后，接下来由日志分析服务来完成日志解析的工作。由于每天每时甚至每分钟产生的日志都非常多，所以需要在服务器空闲的时间对数据里的数据进行分析，日志分析服务在每天的凌晨对数据进行分析整理，得到可以用于展示的数据结果，在通过数据可视化系统将这些数据结果展现出来。
至此，我们的需求分析做完了。下一章，介绍部署和发布。
我收到很多小伙伴的留言，有鼓励我继续完善的，有赞赏监控系统功能价值的，也有质疑我为什么要重复造轮子的。对于这些质疑，其实很简单，作为开发者，不管你想或是不想，线上的问题就摆在那里，只会多不会少。而这套监控系统切实的帮我解决了现实的问题，帮助我提高了开发的效率，希望它也能帮到你。
閱讀更多 一步一個腳印一個坑 的文章
