在实施之前，首先要在脑海中有一个整体的脉络，了解搭建前端监控的具体流程步骤。因为前端监控系统其实是一个完整的全栈工程，不仅仅是前端，甚至主要实现都是围绕数据展开的。当然，还有一点要说明一下，本文的实现主要针对普通业务，针对中小厂的自研方向。我看过大厂做的监控系统，非常复杂，功能强大，动不动就有上亿的数据，最后都往大数据方向发展。我只介绍如何实现主要功能以及如何解决问题。前端监控的构建过程分为以下几个阶段：采集阶段：数据采集API阶段：构建API应用，接收采集数据数据存储阶段：API应用对接数据库，保存采集数据查询统计阶段：采集数据查询、统计、分析可视化阶段：前端通过API查询统计数据，可视化展示告警阶段：API对接告警通知服务，如钉钉部署阶段：应用整体部署上线.我来梳理一下每个阶段的关键实现思路。收集阶段：将收集哪些数据？监控的第一步是收集数据，有数据是监控的前提。采集数据的意义在于记录用户在使用产品过程中的真实操作。结合我们在上一篇文章中的分析，真实操作产生的数据可以分为两类：异常数据和行为数据。我们先分析异常数据。项目中的异常一般可以分为两类，一类是前端异常，一类是接口异常。前端异常大致可以分为：js代码执行异常Promise异常静态资源加载异常控制台。比如类型错误、引用错误等。这些异常大多是由于我们编码不严谨造成的，所以收集此类异常有助于我们提高编码质量。然后是Promise异常。Promise是ES6最重要的属性之一。考验的是我们的js异步编程能力，集中在接口请求上，所以这两部分的异常捕获非常关键。另外，静态资源加载异常一般是指html中引用的一些图片地址，第三方js地址等，由于各种原因导致无法正常加载，这个也要监控。console.error异常通常是第三方前端框架。里面自定义了一些错误，会被console.error抛出。这种异常也是需要捕获的。至于跨域异常，我们经常遇到，一般在前后端开发的联调阶段就能发现。但是不确定是不是后台突然在线改了一些配置，导致前端跨域了。为了安全起见，应对此进行监控。前端异常合集大概只有这五种，基本涵盖了90%以上的前端异常情况。接口异常属于后端异常，但是接口异常会直接导致前端页面出错，所以此类异常是我们判断线上问题根源的重要依据。接口异常可以根据响应结果分类：无响应/超时响应异常4xx请求异常5xx服务器授权不足有时由于网络问题或服务器问题，前端发起请求后没有收到响应，请求是暂停。是无响应/超时响应异常。对于此类异常，我们可以设置最大请求时间，超时后主动断开请求，并添加接口超时记录。另外我们可以根据HTTP状态码或者后端返回的指定字段，比如error_code，来判断其他类型的接口异常。不管使用状态码还是其他判断方式，只要能区分异常类型即可，这个不是严格要求的。4xx异常类型是请求异常，一般是前端传递的参数有问题，或者接口校验参数有问题。处理此类异常的关键是保存请求参数，方便前端排查问题。5xx错误是由服务器内部处理的异常。这类异常的关键信息是报错时间和返回的异常描述。保存这些将使后端更容易搜索日志。权限不足我认为也是一类重要的错误。因为有些管理系统的权限设计比较复杂，有时界面会无缘无故突然无法通信，影响用户下一步的操作，也需要记录和跟踪。虽然这里只列出了三种最常见的类型，但自主开发的监控系统的优势之一就是灵活性。如果您的业务场景有更复杂的异常，那么您完全可以根据业务的实际情况设计更适合的异常分类，只要最终目的是帮助我们更好的跟踪和快速解决问题即可。这个阶段很关键，是监控系统设计的核心，所以写的很详细，大家多想想这个阶段采集什么数据。后面的阶段都是基于这个设计的具体实现。API阶段：构建上报数据的API接口。在前一阶段，准备了数据收集计划。数据采集??完成后，接下来会上报数据。数据上报说白了就是通过调用API接口将数据传输到数据库中。因此，本阶段的任务是构建一个用于上报数据的API接口应用。作为一名光荣的前端工程师，自然而然会选择属于JS家族的Node.js来开发界面。Node.js目前有很多框架。我比较喜欢轻量简洁的，又需要自己安装，所以选择简洁经典的Express框架。构建一个API应用需要做的事情有：目录结构设计路由设计鉴权鉴权参数验证请求响应封装错误处理等一些细节。这个阶段对于后端基础薄弱的同学来说是一个非常好的学习机会。强烈建议前端的小伙伴掌握一些后端的基础知识，至少从简单的原理上明白是怎么回事。这个阶段主要是了解API应用程序是如何构建的，为什么每个部分都这样做，可以解决什么问题，这样你的后台基础知识就建立起来了。框架搭好后，主要要做的就是设计接口URL，然后编写处理逻辑，保证这一步设计的接口可以调整，可以接收数据。数据存储阶段：接口对接数据库在上一步中，我们构建了API接口，接收了采集到的数据，接下来我们的步骤就是连接数据库，将采集到的数据存储到数据库中。数据库选择MongoDB，属于NoSQL家族的文档数据库，对前端最友好。这个数据库最大的特点就是存储的数据格式类似于JSON，操作就像在JS中调用函数，结合JSON数据。我们前端非常容易理解和上手，大家可以在实战过程中体会。优雅的。数据存储阶段主要介绍数据库的基本信息和操作，包括以下几个方面：如何连接数据库，如何设计字段，如何校验，如何写入，如何查询。这个阶段的关键是数据验证。在设计好数据库字段之后，我们希望所有写入的数据都必须符合我们想要的数据格式。如果验证不匹配，我们可以补充或修改数据字段，或者直接拒绝写入，这样可以保证数据的可靠性，避免不必要的数据清洗。完成写入数据的工作后，应该增加一些简单的查询和修改功能。因为写数据后想看是否执行成功，所以可以查一个list看结果。修改函数也是必要的。前端监控中一个很常见的需求就是计算用户的页面停留时间。我的方案是在用户进入某个页面时创建一条记录，然后在离开时修改这条记录，增加一个结束时间字段，需要修改功能。最后想提一下，很多人都在讲如何做数据清洗。其实这要看你之前存数据的时候验证的好不好。如果确实可以存储无效数据，那么可以写一个清除数据的接口，自己写一个清除逻辑，然后定时执行。查询统计阶段：数据查询和统计分析。经过一系列的准备，我们完成了API接口和数据写入的功能。假设我们收集了足够多的数据并存储在数据库中，这个阶段就是利用好这些数据的时候了。这个阶段的主要任务是对数据进行检索和统计分析，基本属于“查询”操作。这里的查询不仅仅是查，如何查是关系到我们收集到的数据能否得到有效利用的。我的想法是从这两个方面入手：行为数据和异常数据当然，这只是一般情况。行为数据也将被单独查询。比如我想看某个用户在某个时间做了什么，这就是精准搜索。异常数据也有统计，比如异常接口触发频率排名。行为数据量会非常大，在用户使用系统时会频繁产生并频繁写入数据库。因此，在大多数情况下，这类数据都是通过聚合查询从页面、时间等多个维度进行整体统计，最后得出一些百分比结论。这些统计值可以大致反映产品的实际使用情况。这里有一个优化点，因为频繁的请求会增加接口的负担，所以也可以先将一部分数据存储到本地，达到一定量后再请求接口，一次性存储。异常数据对于开发者来说非常重要，是我们定位和解决bug的神助攻。与行为数据的多项统计不同，对于异常数据，我们更关心的是每一条记录的详细信息，这样一目了然。异常数据查询也比较简单，和普通的列表查询一样，只需要返回最新的异常数据即可。当然，我们在排查问题之后，也要将处理过的异常标记为已处理，防止重复排查。可以看出，这个阶段最重要的是做统计界面，为下一阶段的可视化图表展示做准备。可视化阶段：最终的数据图表展示在上一阶段，我们开发了一个统计界面，找出了想要的数据结果。不幸的是，这些结果只能被程序员理解，其他人未必能理解。所以最后为了更直观的体现数据，我们需要借助前端可视化图表，让这些数据活起来。这个阶段，我们终于回到了最熟悉的前端领域。这个阶段的任务比较简单顺利。新建一个基于React的前端应用，连接上一步的统计接口，然后集成前端图表库，将统计结果以图表形式展示。这个新的应用是一个真正要对外展示的前端监控系统。供团队内部的开发或产品同学使用，可以实时查看产品产生的数据信息，从而解决自己的问题。其实现阶段没有什么关键问题要讨论，主要是选择好用的图表库和对接接口。还有各种类型的图表。需要考虑哪些数据适合哪些图表，根据实际情况做出判断。最后，监控系统的前端页面和接口数据一定不能让大家看到，所以要有一个基本的登录页面和功能。做到这一点，这个阶段的任务就结束了。报警阶段：当发现异常时，立即报警通知上一级。监控系统前端搭建完成，将统计数据以图表形式展现后，整个监控系统就基本可用了。但是还有一种情况，就是用户在使用我们的产品的时候突然报错，并且报错信息也写入了数据库。如果这时候你不主动刷新页面，其实就是一直刷新不下去，那我们根本就不知道这个错误。如果这是一个影响范围很广的致命bug，而我们连这个bug都不知道，那会给我们造成很大的损失。因此，为了保证我们及时解决bug，告警通知功能就显得非常重要。它的作用是一旦出现异常就推送给开发者，让大家第一时间发现问题，然后尽快解决，避免遗漏。对于告警通知，现在常见的方案是对接钉钉或者企业的微信机器人。我们这里用的是钉钉。使用哪个平台取决于你的主体在哪个平台。比如我的团队主体是钉钉，所以在发送报警通知的时候，可以直接用手机号@任何一个团队成员，实现更精准的提醒。这部分是对API应用的补充。申请钉钉开发者权限后，访问API中的相关代码。部署阶段：万事俱备，只等前几个阶段再上线。我们完成了数据采集、API应用搭建、数据存储、前端可视化展示、监控告警。整个前端监控系统功能齐全。最后一步就是将所有的前后端数据库部署到线上，供大家访问。部署部分主要是nginx分析、https配置、数据库安装、nodejs应用部署等，这个阶段的内容会更多的是运维方面的内容。不过不用担心，我也会在这里对关键操作进行详细的介绍。当本系统上线后，你可以尝试按照第一篇中的采集方式，将采集到的数据通过API保存在你的任意一个前端项目中，然后登录监控系统查看真实使用情况数据。当这部分完成后，恭喜，一个小型的前端监控系统已经搭建完成。未来我们可以在此基础上继续扩展功能，逐步让这个自主研发的监控系统变得更加强大。总结本文介绍了前端监控系统的搭建过程，将整个过程分为几个阶段，简要说明每个阶段要做什么，有哪些关键问题，帮助大家理清思路构建监控体系。
