当前位置: 首页 > 后端技术 > Node.js

如何提高后台服务应用问题的排查效率?日志VS远程调试

时间:2023-04-03 17:39:17 Node.js

转眼Jerry的最新文章推送已经一个多月了。公众号更新频率降低,不是因为Jerry偷懒,而是因为从春节开始,我所在的SAP成都研究院数字创新空间整个团队都在忙一个项目,需要更新五月交付。Jerry每天的工作量如下图所示:在这个项目中,Jerry负责后台开发。我用nodejs开发了几个微服务,每个微服务都实现了特定的业务逻辑。这些微服务由Jerry开发的编排器(Orchestra)统一调度。整个后台实现部署在AmazonWebService(以下简称AWS)上。交期越来越近了,我们的功能也差不多赶上了。本地测试运行良好,但部署到AWS后出现一些bug。比如我昨天遇到了一个棘手的bug,才有了今天的这篇文章。2014年五一前一天,Jerry还在SAPCRM开发组工作,负责处理SAPCRM中间件的一个bug。这个错误与代码执行的时间有关。每次执行只有40%的几率重新出现。调试花了我一整天(8小时)。因为重现bug的场景太复杂,需要调试的ABAP代码量太大,印象深刻。bug处理完后,我也对我花了8个小时修复bug的效率很不满意,所以写了一篇博客来总结这次排错的经验教训:我的Tipsabouthowtohandlecomplexandtrickyissueshttps://blogs.sap.com/2014/05...回到昨天在AWS上遇到的bug,根据问题的表现,一开始我和同事负责前端发展。后端没办法判断。微服务部署到本地测试时一切正常,只有部署到AWS上进行集成测试才会暴露出来,而AWS上运行的nodejs应用,昨天不知道怎么调试,于是有了用我大二刚学C语言编程时用过的最笨的排错方法:日志记录。2001年,在完成一年的计算机基础课程学习后,Jerry开始学习Unix环境下的C语言编程。当时我对gdb这种使用命令提示行的调试方式很不适应。很多时候,我都是通过在代码中加入printf语句的方式来打印变量内容,被宿舍同学鄙视了很久。于是昨天我继续沿用18年前的排错方法:1.在相关代码中一条一条的添加日志输出语句可能会出bug2.执行会出bug的用户操作3.阅读AWS上的以上三步生成日志语句是一个迭代过程。一开始我加了一些日志输出语句,执行完运行后,读取生成的日志,发现没有异常。于是不断添加新的日志打印代码,最后执行一个操作,会产生1200行日志输出。我和负责前端开发的同事坐在显示器前,逐行查看海量的日志输出。由于问题是在用户第二次操作后才暴露出来的,每次操作都会产生不同的session,我们只好不断上下滑动屏幕来比较两次session的uuid和相关的WebSocketuuid等变量.杰瑞很快发现,眼睛一眨不眨地盯着监控器,一条一条地查看日志,时间一长,眼里的疼痛就变得难以忍受了。无奈之下,我只好用打印机把这些日志打印出来,用不同颜色的笔标出两个session对应的各种变量,在纸上来回对比。于是就有了下面的论文:虽然最后用这个方法成功排除了后台出错的可能性,让我们可以把精力花在前端代码的review上,但是正如我的一个同事评论的,“这种方法太不环保了”,我也觉得效率太低了。后来几个热心的同事告诉Jerry,即使是运行在SAPCloudPlatform或AWS等云平台上的nodejs应用程序,也可以在a中调试单步,Jerry谷歌了一下,发现远程调试真的很简单,两条命令就可以了,Jerry用我们创新空间团队的另一位同事Haytham开发的nodejs应用,部署在AWS上为例,尝试在上面调试Haytham虽然是大四本科生,但是在SAP成都研究院Jerry的团队实习了将近十个月,最近三个月一直在SAP德国总部参与一个项目的开发。Haytham回到成都后,将以SAP新人的视角分享他十个月的工作心得,敬请期待。Haytham上一篇文章:SAP成都研究院许巨龙:你好,Coresystems!这个由Haytham编写的nodejs应用程序实际上是GithubWebhook的一部分。我们在本地开发微服务nodejs,本地git客户端推送代码到远程github仓库。然后需要在AWS上手动gitpull拉取最新的代码,然后使用一个开源工具pm2进行微服务部署。Haytham编写的nodejs应用在本地gitpush完成后,可以完全自动化所有后续流程,为我们节省了大量的部署时间。让我们远程调试Haytham,这是一个在AWS上运行的nodejs应用程序。1.使用node--inspect-brk在AWS上以调试模式启动应用程序。然后控制台的输出显示在地址127.0.0.1:9229上有一个nodejs进程监听调试客户端使用WebSocket协议的连接。2.在我的本地电脑上,我使用如下命令行将我本地电脑的9221端口映射到AWS调试进程监听的9229端口:ssh-iC:Usersi042416.sshKOI.pem-L9221:localhost:9229ubuntu@ec2-us-east-2.compute.amazonaws.com现在在本地电脑上,Chrome浏览器地址栏chrome://inspect指定监听地址为localhost:9221,通过第二步建立的SSH隧道,我可以使用本地计算机连接到AWS上的nodejs应用程序并进行调试。现在终于可以愉快的在Chrome开发者工具中调试了:因为我平时在本地做nodejs开发调试的时候比较喜欢用VisualStudioCode,所以接下来打算试试用VisualStudioCode进行远程调试。说到VisualStudioCode,Jerry突然想起了今天在网上看到的这个IDE的一个有趣的扩展,叫做“BeyondEncouragement”。Jerry试着在他的VisualStudioCode扩展安装栏里搜索了一下,果然这个扩展是可以下载的。然而,“杨超越”出现在分机,杰瑞又懵了。他是在咨询了他的妻子之后才知道她是谁的。至于实际效果,杰瑞不予置评。欢迎VisualStudioCode爱好者自行下载体验。最后,祝愿所有的程序员/程序猿即使每天没有程序员鼓励者的陪伴,依然可以愉快地编程。谢谢阅读。获取更多Jerry原创文章,请关注公众号“王子熙”: