书名：从零开始搭建前端监控平台
ISBN：978-7-115-53262-6
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 陈 辰
责任编辑 杨海玲
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书从实际开发工作中遇到的问题出发，从前端工程师的角度实践从零开始搭建一个前端监控平台。本书共分为8章，第1章和第2章分别介绍搭建前端监控平台的必要性以及如何确定前端监控平台的功能，第3章介绍数据上报的方法，第4章介绍前端监控平台各功能模块的总体设计，第5章介绍相关数据处理工作，第6章和第7章分别介绍后端服务搭建和前端界面搭建，第8章介绍前端监控平台的具体使用场景。
本书内容通俗易懂，实践性强，适合任何对监控平台开发感兴趣的工程师阅读，也适合希望减轻前端监控成本的团队领导者参考。
很久以来我一直想把自己的知识梳理一下，然后分享给大家，但是一直没有时间和机会。机缘巧合，在慕课网上讲授“性能优化”系列课程，让我积累了一些分享技术的经验，并具备了一定的总结能力。
现在市面上的大多数监控平台是对性能、网络环境或者产品指标进行监控的。这些平台都非常优秀，但是它们也都在不同程度上存在一定的弊端。
（1）这些平台几乎都是收费的，有的跟云服务打包出售，有的单独出售。
（2）这些前端监控平台的架构都是不开源的，大多数开发者没有办法对这类前端监控平台通过二次开发得到自己想要的前端监控平台，也就没有办法把非开源的前端监控平台改成适合自己项目的前端监控平台。
（3）这些前端监控平台大部分不支持私有化部署，也就是说，前端监控平台的数据不在用户自己手里，而是在前端监控平台的供应商手里。
（4）这些平台的功能定制化能力比较差，这也在情理之中，因为通用性能做得好的平台，定制化能力或多或少会受到影响。
（5）很少有监控平台监控前端报错信息，而是期望测试人员和用户去发现前端问题。如果是测试人员发现问题还好，问题可以得到及时解决，但是如果是用户发现问题，那就可能比较严重了，有时甚至会导致客户投诉，直至演变为网络舆情。
提示
客户投诉是指客户对企业产品质量或服务不满意而提出的书面或口头上的异议、抗议、索赔和要求解决问题等行为。
网络舆情是指在互联网上流行的对社会问题不同看法的网络舆论，是社会舆论的一种表现形式，是通过互联网传播的公众对现实生活中某些热点、焦点问题所持的有较强影响力、倾向性的言论和观点。
基于上述介绍的5个弊端，结合我任职公司现有的几百条产品线缺少一个前端监控平台的现状，我和一些优秀的同事们开发了一个名为“灯塔”的前端监控平台项目，也就是开源项目Fee的前身。本书讲述的内容是以开源项目Fee为代码基础的前端搭建的全部流程。
前端工程师经历了从“切图仔”到“工程师”的转变。虽然在部分工程师眼中，前端工程师还处于互联网工程师生存链的底部，但我相信，前端工程师离用户最近，担负的责任也大，有时候出现问题都是前端人员先排查。因此，我萌生了写一本搭建前端监控平台的书的想法，希望能让离用户最近的人更早知道用户的 问题。
本书共分为8章，是按照从抛出问题到解决问题的思路组织内容的。第1章和第2章介绍的是一个技术类项目需求从无到有的过程。第3章到第7章介绍的是前端监控平台搭建的具体实践。第8章介绍了前端监控平台的使用场景及其面对的挑战。
第1章介绍搭建前端监控平台的必要性，以前端监控平台具体解决的问题为切入点，结合真实用户场景，分别阐述了前端监控平台对于前端稳定性的重要程度和对前端工程师成就感的激发。
第2章主要介绍如何确定前端监控平台的功能，如何梳理技术类项目的需求。从用户登录失败、服务器页面加载失败、混合App内部报错、服务器接口返回错误数据4个方面设计出前端监控平台涵盖的主要功能。
第3章介绍数据上报（埋点）的方法，从自动上报和手动上报两个方向对数据进行分类。自动上报的数据通常为错误类型数据、性能相关数据、环境相关数据；手动上报数据通常为用户行为数据和流程错误数据，并且剖析了用1像素× 1像素的gif图上报数据的根本原因。
第4章主要是梳理平台在开发阶段需要做的事，交代了前端监控平台在业务系统中所处的位置，以及前端监控平台的内部设计原理。
第5章介绍前端监控平台的数据处理工作，从数据入口——服务器日志开始，到消息系统、临时日志存储，介绍了前端监控数据流转的全过程。还介绍了在这个数据全流程当中指令系统和任务系统是如何设计、工作的。
第6章介绍后端服务搭建，从最常见的数据库增、删、改、查操作，到服务器接口的设计开发，从功能角度详细介绍了登录相关接口、错误相关接口、报警相关接口、性能相关接口的设计和用途，并且对本书中最重要的内容——错误接口的实现进行了代码级别的讲解。
第7章介绍前端界面搭建，从站点开发的整体流程入手，其内容是按照模块划分、配置模块、类库依赖、页面路由、静态资源和数据展示的顺序构思的。7.6节用很大篇幅来介绍前端监控平台三大主界面（报错主界面、性能主界面、报警主界面）的开发思路和实现代码。
第8章主要介绍一些平台搭建之后的使用场景，还介绍了前端监控平台后续遇到的一些新挑战。
附录的主要内容是作者在开发前端监控平台时碰到的一些细节问题和这些问题的解决方案。
本书不但适合前端工程师，而且适合后端工程师、移动端工程师，因为本书讲述的是如何从零开始搭建一个前端监控系统，并不限定读者必须用哪种技术完成开发。如果你是一个团队的领导者或者技术骨干，想比用户更早发现错误，但又不想花钱购买前端监控服务，也不想把自己的数据上报给第三方平台，就是想从无到有搭建一个监控平台的话，那么本书很适合你。
阅读本书之前，我们希望你具备一定的前、后端开发经验，熟悉常规的数据库操作，至少搭建过“Hello World”级别的后端服务。如果读者在阅读本书之前还了解一些数据清洗或任务调度的概念，将有助于理解本书的内容。
本书的实例代码是以GitHub上的开源前端监控项目Fee作为基础，Fee项目是以MIT协议开源，读者可以从GitHub平台上直接下载Fee项目，任何人都可以直接使用它或将它改造成自己想要的前端监控平台。强烈建议对照开源项目代码阅读本书，因为本书中示例代码均为关键代码，而开源项目代码为完整项目代码且可执行。技术人员对照功能调试代码是熟悉项目的最快渠道，希望读者读完本书之后能够开发出比Fee更好的监控平台。
开源项目Fee是贝壳找房前端监控“灯塔”的开源版本，是经过公司TC（技术委员会）和安全部门审核同意后进行开源的。
感谢廖雪峰和杨永林两位前辈，在他们的不断鼓励下我才能完成这本书；感谢贝壳找房整个前端工程师团队；感谢我的搭档董亚杰先生和曹奋泽先生；感谢王超先生和黄国伟先生，他们帮我和贝壳找房前端架构组扫清了前进路上的所有障碍；感谢贝壳找房前端架构组的成员对开源项目Fee的贡献，他们是姚泽源、韩庆新、廖琪欣、刘江虹、李思嘉、彭元元、孙振超、王强、高吴蔓、黄伟、李俊冬、夏园园、庞凤、马琳、朱敏、顾黎明和米启蒙。
特别感谢姚泽源、韩庆新、邹琴、王怀爽利用业余时间对本书的技术内容进行审校。
感谢我任职过的每一家公司：联想、百度、简谱科技、阿里巴巴，以及我现任职公司贝壳找房。每一次的工作经历都使我在能力和视野上有了长足的进步。
最后，感谢人民邮电出版社的杨海玲编辑。
本书由异步社区出品，社区（https://www.epubit.com/）为你提供相关资源和后续服务。
本书提供源代码下载。要获得以上配套资源，请在异步社区本书页面中单击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎你将发现的问题反馈给我们，帮助我们提升图书的质量。
当你发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对你提交的勘误进行审核，确认并接受后，你将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
扫描右侧二维码，你将会在异步社区微信服务号中看到本书信息及相关的服务提示。
我们的联系邮箱是contact@epubit.com.cn。
如果你对本书有任何疑问或建议，请你发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果你有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线投稿 （直接访问www.epubit.com/selfpublish/submission即可）。
如果你来自学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果你在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请你将怀疑有侵权行为的链接发邮件给我们。你的这一举动是对作者权益的保护，也是我们持续为你提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
每一个平台的形成都源自于广泛的需求，抽象出这些需求的公共特性所形成的产品叫作平台。
在加入贝壳找房后，多个业务产品线的技术人员都跟我提起过，他们想知道线上前端页面报错的情况，想知道页面的性能如何，也想知道使用我们产品的人到底使用的是什么设备。这就是监控平台形成的前提条件，也是必要条件。在本书中，我会以Fee作为前端监控平台的代号。
提示
Fee是以贝壳找房“灯塔”前端监控项目为基础架构的开源项目代号，由于本书的代码是以GitHub上开源项目Fee的代码作为参考代码的，因此为了方便大家识别，在本书中前端监控平台以Fee作为简称。
在站点线上运行阶段，稳定性问题是最重要的问题。一旦稳定性出现问题，站点访问用户会感觉操作不流畅，产品流程阻塞，甚至会出现网页无法显示的状况。
有一种情况是在后端接口突然上线的情况下，某个接口反馈数据格式错误。如果接口数据无法被前端代码正常解析，就会造成JavaScript解析错误，将直接导致用户看到的网页没有任何内容，影响用户使用体验。如果没有监控平台的话，当我们发现问题的时候，可能已经流失了很大一部分用户了。
另一种情况是在前端项目刚刚上线时出现问题。这类问题在测试阶段往往可以发现，因为在大多数公司的上线流程中有线上回归测试。这类测试主要是在线上环境最后验证上线部分功能的可用性。但是回归测试毕竟是由人来操作的，是人就难免会犯错，我们也不能保证所有的问题都能被测试工程师发现。因此在上线之后观察监控平台的错误数据，其实也解决了在项目上线过程中出现问题的情况。
Fee 项目最开始起源于一款客户端项目（该项目主要是一款Windows套壳程序）。该客户端项目使用NW.js技术进行开发，但是根据实际用户反馈，使用过程中该客户端会有较大概率崩溃，而且NW.js 1.4支持Windows XP，NW.js 2.0只支持Windows 7。那么问题来了，我们的项目到底要支持哪个系统？是不是都要支持？为了分析这些问题，我们做了图1-1所示的Fee平台的系统发布功能。在图1-1中，“系统发布”模块可以展示用户实际的使用设备信息、浏览器信息、设备分布和应用版本分布。这些功能有助于我们判断用户实际使用场景。
图1-1 Fee平台的“系统发布”模块
提示
所谓 Windows 套壳就是一款Windows程序。项目原理是项目外层以一个C++程序作为运行容器，内部的内容均由前端页面代替，这样能保证迭代更迅速且不需要版本发布。
提示
NW.js是基于Chromium和Node.js的。它允许我们直接从浏览器调用Node.js代码和模块，并在我们的应用程序中使用Web技术。此外，我们可以轻松地将Web应用程序打包到本机应用程序。
如果bug是必现的，那么其实非常好解决。但是如果bug不是必现的呢？指望普通用户或者非技术人员来引导你修复bug，显然不是一个好主意。因此，又多了一个问题，即根据bug出现的时间，观察当时bug产生的环境数据，无论是bug的个体数据还是bug整合之后的趋势数据（主要是版本发布、接口上线造成的瞬时问题，也有可能是特定版本对某一系统本身存在的问题），根据这些数据及时寻找并解决用户反馈的问题。为了快速有效地定位问题，我开发了图1-2所示的崩溃和错误趋势图。
图1-2 监控平台的崩溃和错误趋势图
后来，在跟所在公司各个团队前端负责人的碰头会中，我发现大家都有这样的问题，比如，某团队出现了一个问题，用户反馈手机端进入交易历史记录页面后白屏，但是这个问题并不是必现的，而且用户（这里的用户指的是使用站点的普通用户）只能表述问题的现象。由于用户是非技术人员，所能提供的信息往往也不能帮助我们直接定位问题关键点，更没有办法辅助我们修复bug，而且问题是非必现的，非必现类bug不能复现，因此修复这类bug往往很困难。修复bug的一个关键点就是如何保留bug出现的现场。毫无疑问，bug的堆栈信息是解决bug的重要现场。图1-3所示就是一个图片加载失败的bug堆栈信息。这个堆栈信息描述的是在aaaa.*****.com域名下某张图片加载失败了。因此具体bug的堆栈信息也是前端监控平台不可或缺的功能。至此，我们已经介绍完前端监控平台大部分功能的使用场景。
图1-3 图片加载错误栈信息
不知道大家是否碰到过这样的一个场景：突然有一天，老板拿了一个不知名的手机（也可能是某知名品牌）问你一些问题，“为什么我的手机看不了”“为什么我用不了咱们新上的功能”。为了回答老板的问题，我们必须研究某些功能为什么不兼容老板的手机，然后为了解决这个问题，我们必须尝试写一些破坏代码整体逻辑的兼容代码，也许这个兼容代码会在后续的开发任务中把你拖进问题深渊。也许兼容老板的手机所花费的时间，比开发这个功能所消耗的时间还要长。我个人并不完全认同“面向老板”的编程。因此，我需要用数据向我的老板证明，他用的手机很可能不是我们的主要用户所使用的。我们可能需要一个图1-4所示的设备分布饼状图来分析设备占比，从而使功能更好地满足用户的需求。
图1-4 设备分布饼状图
在前端项目的优化方案中我们常常会提到“前端性能优化”这个词，“前端性能优化”流程的第一步就是获取前端性能数据的现状，第二步是研发人员针对要提升的关键前端性能数据给出解决方案，最后在前端性能优化解决方案上线之后，根据上线之后的前端性能数据评价本次方案是否成功。因此，如果某个前端项目要进行前端性能优化，收集、展示前端性能监控数据的这个功能是前端监控平台必不可少的。
此外，前端开发者还需要使用前端性能数据看板功能来对比性能优化之前和优化之后的情况。图1-5所示为前端性能关键指标耗时功能展示，图1-6所示为监控平台页面总体性能指标。至此，我们已经介绍完前端监控平台大部分功能的使用场景。
图1-5 前端性能关键指标耗时模块
图1-6 监控平台页面总体性能指标
以上就是前端监控平台所包含的稳定性功能。接下来在1.2节中将介绍前端监控平台解决的另一个问题——技术产出。
在项目还没有启动的时候，整个前端团队在讨论项目的过程中突然抛出了一些问题：平时业务开发时，开发工程师不断接入新需求，开发新功能，到底是为了什么？我们只是支撑团队吗？我们经常强调要把业务当作自己的项目，但是成就感来自何处？大家均感觉最主要的成就感来自对业务的贡献。说得直白一点，也就是项目做完之后有多少人用，增加了多少收入。那么，我们开发的既然是一个解决问题的平台，能不能在我们做了技术方案之后，也来评估一下这个技术方案是否是有效的呢？（我认为方案能为公司层面或者产品层面提升多大收益是评价方案是否优秀的唯一标准，而不是方案的技术有多么高深。前端方案的追求应该是有效、稳定、快速。）
在我有了这个想法（技术产出其实是由业务好坏来衡量的）之后，我跟组内的大多数前端工程师沟通了一次，发现大家有对于成就感的困惑，然后我在几个前端团队中发起了一个问卷调查，问卷调查的内容是“如果有一个功能帮助你统计你开发的功能模块的具体使用情况，你们会去用吗？”。问卷的结果几乎都是他们一定会去用。后来这个功能上线了，还让开发人员有了意外的收获，就是在产品经理提出同类型产品需求的时候，如果上次产品效果不好，我们就会质疑产品经理提出的这个需求。因此，在前端监控平台的需求里又多了一个功能——业务模块使用情况（如图1-7所示）。
图1-7 业务模块使用情况
后来应业务方前端工程师的诉求，我们又加入了一个统计业务模块使用时间的功能，用来统计业务模块的使用频次，从而评估业务模块在低频次使用情况下的开发价值。例如，用户平均在线时长就可以是我们关注的一个指标，如图1-8所示。
图1-8 用户平均在线时长
本章以实际生产项目中遇到的问题为基础，深入问题本质挖掘前端监控平台的需求。从解决这些问题和如何体现技术价值两个不同的角度出发，总结出了一个高质量的前端监控平台所需要的主要功能。同时这些问题也折射出了我们确实迫切地需要一个这样的前端监控平台来解决问题。
注意
结合第1章中监控所解决的问题，本书定义的前端监控平台的使命是：“让我们能够比用户更早发现问题，并且能在用户发现问题之前解决问题，通过产品或者业务数据体现前端工程师的价值。”因此，前端监控平台的核心需求都是以此为基础的。
