🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
  当运营向我们上报BUG时,我们第一时间是捕获相关的接口。从[监控系统](https://www.cnblogs.com/strick/p/14577054.html)中,就可以查到用户使用时接口的请求和响应数据。   若接口的请求正常,那么就需要深入到接口代码中,查看相关的日志,通常会先浏览数据库查询语句以及内部接口的通信日志。   在本地也可以查看到上述日志,但有个问题,有时候打开某个页面会报错,那是因为本地的数据库没有与测试或正式环境的同步。   可能是有些字段缺失了,也可能是某张表缺失了,情况比较多。所以,最保险的是在测试或正式环境查看。   在这两个环境中,都有日志管理系统,但日志量是非常巨大的,若要查找某一条记录,就得有非常精确的过滤条件,并且日志无法连续。   这条日志下面的一条,很可能是另外一个接口留下的,因此,需要一个小工具能查看到指定接口的日志,解决日常开发的一个痛点。 ## 一、搜集日志 **1)管理系统**   首先需要将需要的日志搜集起来,我使用了一个比较简单的方法。   就是在启动文件中,新增一个全局的logMessages变量,声明为一个空数组。 ~~~ global.logMessages = []; ~~~   然后在MongoDB、MySQL、请求内部接口函数中,将他们的查询语句日志和通信日志塞入logMessages数组内。 ~~~ mongoose.set('debug', (...args) => { logger.debug(...args); global.logMessages.push(args); }); new Sequelize(database, username, password, { ...options, logging: (msg, benchmark) => { logger.debug(msg, `${benchmark}ms`); global.logMessages.push(msg); } }); ~~~   再新增一个中间件(Server项目基于KOA2),这个中间件的作用就是清空logMessages数组,免得将所有接口的日志都搜集起来,因为我只要一个接口的日志。 ~~~ export default () => async (ctx, next) => { //每次请求清空要读取的日志数组 global.logMessages.length = 0; await next(); }; ~~~   这么设计会有一个问题,服务器在处理多个请求(高并发)时,互相会影响各自的日志搜集,可能会出现这个接口日志中夹杂着另一个接口的日志,也可能是搜集到一半的日志就被清除了。   当然,在测试环境,这种情况可以控制住。但是测试环境有时候数据不完整,逻辑可能走不下去,得上生产环境,那生产环境就有概率出现上述问题。   后面将中间件去除,logMessages变量在一个接口中声明,这个接口就是下面界面中点提交时请求的接口,能解决日志被无故清除的问题,但还是会出现串线的问题。   生产环境暂时无解,好在还有一个预发环境,它使用的数据源和生产是相同的,只要保证代码和生产同步,那么就能得到想要的日志列表。 **2)Web API**   Web API是另一个接口服务,也需要监控其中的日志,但是它与之前的管理系统不同,它是一个独立的服务。   也就是说,我无法直接在管理系统中通过 global.logMessages 读取日志。   一开始是想将日志写入缓存中,然后在管理系统中读取缓存中的日志,不过这样做不仅太绕,平添复杂度,而且日志写法也会与之前的不一致。   于是否决了此方案,改用一个中间件,日志的写入和读取与之前保持一致。不同点是在一个中间件中,将日志作为响应的参数返回。   在下面的代码中,当需要日志时,我会带上一个特殊的参数:isLogMessages,只有这个参数存在时,才表示需要返回记录。 ~~~ export default () => async (ctx, next) => { // 只有带了特殊参数的请求,才会把接口日志带上 const isLogMessages = ctx.query.isLogMessages || ctx.request.body.isLogMessages; if(isLogMessages) { global.logMessages = []; } await next(); if(isLogMessages) { const { body } = ctx; if(typeof body === 'string') { ctx.body = { data: body }; }else { ctx.body = { ...body } } ctx.body.logMessages = global.logMessages; delete global.logMessages; } ~~~ ## 二、界面   在完成上述的日志搜集之后,就需要有一张操作界面(如图所示),提升我们组自己的用户体验,借助之前封装的[模板组件](https://github.com/pwstrick/shin-admin/blob/main/docs/template.md),搭建这样一个页面几十分钟就好了。 :-: ![](https://img.kancloud.cn/fe/3b/fe3b86f5bf1f11406ac264caa614d5ce_1350x620.png =600x)   界面中包括API路径、方法、项目和参数,其中参数可动态增加,点击提交就会开始模拟请求接口,得到日志(如图所示)和响应。 :-: ![](https://img.kancloud.cn/d3/80/d3801fb832c0cb0bb6e53523d6435680_2488x350.png =800x)   这样一套操作之后,就能马上知道接口内的细节,可帮助我们快速定位问题,也是一种降低时间成本的手段。 ***** > 原文出处: [博客园-Node.js躬行记](https://www.cnblogs.com/strick/category/1688575.html) [知乎专栏-Node.js躬行记](https://zhuanlan.zhihu.com/pwnode) 已建立一个微信前端交流群,如要进群,请先加微信号freedom20180706或扫描下面的二维码,请求中需注明“看云加群”,在通过请求后就会把你拉进来。还搜集整理了一套[面试资料](https://github.com/pwstrick/daily),欢迎阅读。 ![](https://box.kancloud.cn/2e1f8ecf9512ecdd2fcaae8250e7d48a_430x430.jpg =200x200) 推荐一款前端监控脚本:[shin-monitor](https://github.com/pwstrick/shin-monitor),不仅能监控前端的错误、通信、打印等行为,还能计算各类性能参数,包括 FMP、LCP、FP 等。