完整解决方案:JavaScript架构前端监控搭建过程步骤

　　完整解决方案:JavaScript架构前端监控搭建过程步骤

　　目录

　　前言

　　上一篇介绍了为什么前端会有监控系统？前端监控系统有什么意义？有朋友看完后留言，想听听一些详细的实现。那么在本文中，我们将开始介绍前端监控是如何实现的。

　　如果还是不明白为什么，监控有什么用，推荐阅读上一篇文章文章：前端为什么不能没有监控系统？

　　在实施之前，首先要在脑海中有一个整体的背景，了解构建前端监控的具体流程步骤。因为前端监控系统其实是一个完整的全栈项目，不仅仅是前端，甚至主要的实现都围绕着数据。

　　当然，还有一点需要说明。本文的实现主要针对普通业务和中小厂自研方向。我看过大厂做的监控系统。它非常复杂和强大，动辄数以亿计的数据。最终走向了大数据的方向。我只介绍如何实现main函数，如何解决问题。

　　前端监控的构建过程分为以下几个阶段：

　　下面我来梳理一下各个阶段的关键实现思路。

　　采集阶段：采集什么数据？

　　监控的第一步是采集数据。有数据是监控的前提。

　　采集数据的含义是记录用户在使用产品过程中的真实操作。结合我们上一篇的分析，实际操作产生的数据可以分为两类：异常数据和行为数据。

　　我们先分析异常数据。项目中的异常一般可以分为两类，一类是前端异常，一类是接口异常。

　　前端异常

　　前端异常大致可以分为：

　　最重要的，也是我们遇到最多的，就是各种js代码执行异常。比如类型错误、引用错误等。这些异常大部分是由于我们的编码不精确造成的，所以采集这些异常有助于我们提高编码质量。

　　然后是 Promise 异常。Promise 是 ES6 最重要的属性之一。考验我们的js异步编程能力，主要体现在接口请求上。因此，这两部分的异常捕获非常关键。

　　另外，静态资源加载异常一般是指引用了一些html中的图片地址、第三方js地址等，由于各种原因不能正常加载，这个也要监控。

　　console.error 异常一般用在第三方前端框架中。它自定义了一些错误，会被console.error抛出。此类异常也需要被捕获。

　　至于跨域异常，我们经常会遇到这种情况，通常可以在前后端开发联调阶段发现。但不确定是后端的配置突然在线更改，导致前端跨域。为了安全起见，您还应该对其进行监控。

　　前端异常采集大概只有这5种，基本覆盖了前端90%以上的异常。

　　接口异常

　　接口异常属于后端异常，但是接口异常会直接导致前端页面错误。因此，此类异常是我们判断线上问题根源的重要依据。接口异常可以根据响应结果分类：

　　有时由于网络问题或服务器问题，前端发起请求后没有收到响应，请求被挂起。这次是无响应/超时响应异常。对于此类异常，我们可以设置最大请求时间，超时后主动断开请求，添加接口超时记录。

　　另外，其他类型的接口异常可以根据HTTP状态码或者后端返回的error_code等指定字段来判断。

　　不管是使用状态码还是其他判断方式，只要能区分异常类型，这个不是严格要求的。

　　4xx异常类型是请求异常，一般是前端传递的参数有问题，或者接口验证参数有问题。处理此类异常的关键是保存请求参数，这样可以方便前端排查。

　　

　　5xx 错误是服务器内部处理的异常。此类异常的关键信息是报错时间和返回的异常描述。保存这些可以方便后端查找日志。

　　我认为权限不足也是一种重要的错误类型。因为有些管理系统的权限设计比较复杂，有时候界面突然莫名其妙无法调整，影响用户接下来的操作，也需要记录和跟踪。

　　行为数据

　　行为数据比较广泛，用户任何有意义的操作都可以定义为行为数据。

　　例如，当一个按钮被点击时，它在那里停留了多长时间，新功能的点击率，何时使用等等。自主研发的监控系统的优势之一是灵活性。您需要的任何有用信息都可以在此阶段进行设计。

　　这个阶段非常关键，是监控系统设计的核心，所以我写的很详细，这个阶段大家要多考虑采集哪些数据。后面的阶段都是基于这个设计的具体实现。

　　API阶段：构建上报数据的API接口

　　在上一阶段，采集数据计划已经准备好了。当 采集 数据到达时，接下来会上报数据。

　　说白了，数据上报就是通过调用API接口将数据传输出来，然后存入数据库。因此，这个阶段的任务是构建一个用于报告数据的API接口应用程序。

　　作为一名光荣的前端工程师，在开发接口时自然会选择属于 JS 家族的 Node.js。Node.js 目前有很多框架。我比较喜欢轻量简洁，什么都需要自己安装，所以选择了简洁经典的Express框架。

　　构建 API 应用程序要做的事情是：

　　还有一些细节需要处理。这个阶段对于后端基础薄弱的同学来说是一个很好的学习机会。

　　强烈建议前端的朋友掌握一些后端的基础知识，至少从简单的原理上了解是怎么回事。这个阶段主要是了解API应用是如何搭建的，每个部分为什么要做，可以解决哪些问题，这样你对后端的基础知识就会建立起来。

　　框架搭建好后，主要是设计接口URL，然后编写处理逻辑，保证这一步设计的接口可以调整，可以接收数据。

　　数据存储阶段：与数据库接口对接

　　上一步我们构建了API接口，接收到采集的数据。然后，在这一步中，我们需要连接数据库，并将 采集 中的数据存储到数据库中。

　　数据库方面，选择对前端最友好的，属于NoSQL家族的文档数据库MongoDB。

　　这个数据库最大的特点就是存储的数据格式类似于JSON，操作就像在JS中调用函数，结合JOSN数据。我们很容易理解并开始使用前端。可以在实战过程中体验。优雅也。

　　数据存储阶段主要介绍数据库的基本信息和操作，包括以下几个方面：

　　这个阶段的关键是数据验证。在设计完数据库字段后，我们希望所有写入的数据都必须符合我们想要的数据格式。如果验证后不符合，我们可以补充或修改数据字段，或者干脆拒绝写入，这样可以保证数据的可靠性，避免不必要的数据清洗。

　　数据写入完成后，需要添加一些简单的查询和修改功能。因为要在写完数据后查看执行是否成功，可以查看一个列表来查看结果。

　　还需要修改功能。前端监控中一个很常见的需求就是计算用户的页面停留时间。我的计划是在用户进入某个页面时创建一条记录，然后在用户离开时修改该记录并添加一个结束时间字段，这需要修改功能。

　　最后但并非最不重要的一点是，许多人都在谈论如何清理数据。实际上，这取决于您在将数据存储在您面前时如何验证。如果确实可以存储无效数据，可以写一个清空数据的接口，自己写清空逻辑，定时执行。

　　查询统计阶段：数据查询和统计分析

　　经过一系列的准备，我们已经完成了API接口和数据写入的功能。假设我们有 采集 足够的数据并存储在数据库中，这个阶段就是充分利用这些数据的时候了。

　　这个阶段的主要任务是对数据进行检索和统计分析，基本上是“查询”操作。

　　这里的查询不仅仅是为了检查，如何检查，关系到我们采集到的数据能否得到有效利用。我的想法是从这两个方面入手：

　　

　　当然，这只是笼统的说法。行为数据也将在一行中查询。例如，如果我想查看用户在某个时间做了什么，这就是精确搜索。还有异常数据的统计，比如异常接口的触发频率排名。

　　行为数据量会非常大，在用户使用系统的过程中会频繁生成并写入数据库。因此，在这类数据的大部分情况下，都是通过聚合查询的方式，从页数、时间等多个维度进行整体统计，最后得出一些百分比的结论。这些统计值可以大致反映产品的实际使用情况。

　　这里有个优化点，因为频繁的请求会增加接口的负担，所以一部分数据也可以在本地存储，达到一定数量后，一次性请求并存储接口。

　　异常数据对于开发者来说非常重要，对于我们定位和解决bug来说是天赐之物。与行为数据的多重统计不同，我们更关心异常数据的每一条记录的详细信息，让错误一目了然。

　　查询异常数据也比较简单。和普通的列表查询一样，只需要返回最新的异常数据即可。当然，我们排查问题后，也要把处理的异常标记为已处理，这样可以防止重复排查。

　　可以看出，这个阶段最重要的是做一个统计界面，为下一阶段图表展示的可视化做准备。

　　可视化阶段：最终数据图表展示

　　在最后阶段，我们开发了一个统计界面并找到了想要的数据结果。不幸的是，这些结果只有程序员才能理解，其他人可能无法理解。所以最后，为了更直观的反映数据，我们需要使用前端的可视化图表，让这些数据活起来。

　　在这个阶段，我们终于回到了最熟悉的前端领域。这个阶段的任务比较简单，比较顺利。基于React构建一个新的前端应用，访问上一步的统计界面，然后集成前端图表库，以图表的形式展示统计结果。

　　这个新应用是一个前端监控系统，真正需要展示给外界。供团队内部的开发人员或产品学生使用，方便他们实时查看产品产生的数据信息，解决自己的问题。

　　事实上，现阶段没有关键问题可谈。主要是选择一个好用的图表库并连接接口。还有各种类型的图表。需要考虑哪些数据适合哪些图表，根据实际情况做出判断。

　　最后，监控系统的前端页面和界面数据不是人人都能看到的，所以要有基本的登录页面和功能。做到这一点，这个阶段的任务就结束了。

　　报警阶段：发现异常立即报警通知

　　前一阶段，监控系统前端搭建完成，统计数据以图表形式展示后，整个监控系统基本可用。

　　但是还有另一种情况，就是用户在使用我们的产品时突然报错，错误信息也被写入了数据库。如果此时你不主动刷新页面，实际上你也不能一直刷新页面，那么我们根本不知道这个错误。

　　如果这是一个非常致命的bug，影响范围很广，我们甚至不知道这个bug是什么时候发生的，那会给我们带来很大的损失。

　　所以，为了保证我们能及时解决bug，告警通知的功能就显得非常重要了。它的作用是在出现异常的第一时间推送给开发者，让大家第一时间发现问题，然后以最快的速度解决，避免遗漏。

　　报警通知，现在一般的解决方案是连接钉钉或者企业微信的机器人，我们这里使用钉钉。使用哪个平台取决于您的主题所在的平台。比如我的团队主体在钉钉上，所以在发送报警通知时，可以直接用手机号@任意一个团队成员，实现更精准的提醒。

　　本部分是对 API 应用的补充。申请钉钉开发者权限后，访问API中的相关代码。

　　部署阶段：万事俱备，只等上线

　　前期我们完成了数据采集、API应用构建、数据存储、前端可视化展示、监控告警。整个前端监控系统功能齐全。最后一步是将所有的前端和后端数据库都在线部署，供大家访问。

　　部署主要是nginx解析、https配置、数据库安装、nodejs的应用部署等，这个阶段的内容会多一点运维。不过不用担心，这里我也会详细介绍关键操作。

　　系统上线后，你可以尝试在你的任意一个前端项目中通过API保存数据采集，按照第一篇中的采集方法，然后登录监控系统查看真实使用数据。

　　当这部分完成后，恭喜，一个小型的前端监控系统搭建完成。未来我们可以在此基础上继续扩展功能，慢慢让这个自研的监控系统变得更强大。

　　总结

　　本文介绍了前端监控系统的搭建流程，将整个流程分为几个阶段，简要介绍了每个阶段要做什么，有哪些关键问题，帮助大家理清搭建监控系统的思路，以及更多关于前端监控和构建JavaScript架构的信息，请关注脚本之家文章的其他相关话题！

　　最佳实践:DEDE采集规则过滤与替换

　　删除最常用的超链接。{dede：trim replace=''}]*）>{/dede：trim}

　　{dede：trim replace=''}{/dede：trim}

　　如果你像这样填写它，那么链接的文本也会被删除{dede：trim替换=''}]*）>（.*）{/dede：trim}

　　2、过滤JS调用广告，比如GG广告，添加这样的东西：{dede：trim=''}{/dede：trim}

　　3. 过滤 div 标签。这是非常重要的，如果不过滤，它可能会错放已发布的文章布局，并且当前大多数采集在遇到它之后都放错了位置。{dede：trim replace=''}

　　

　　{/dede：trim}

　　{dede：trim replace=''}

　　{/dede：trim}

　　有时有必要像这样过滤：{dede：修剪替换=''}

　　（.*）

　　{/dede：trim}

　　

　　4.其他过滤规则可以根据上述规则引入。

　　5.过滤经常使用的片段和关键字使用情况。{dede：trim replace=''}{/dede：trim}

　　6.更换简单。

　　{dede：trim replace ='被替换的单词'} 要替换的单词 {/dede：trim}

　　当然，采集的内容也需要搜索引擎收录，过滤和替换的目的是为了减少重复、伪原创，如何具体操作，这取决于个人的要求和喜好。

　　有关更多信息，请参阅 IT 技术专栏