浅谈 OneAPM 在 express 项目中的实践
2016-04-11 15:31
585 查看
为什么我们要使用性能监控呢?
OneAPM 是一个优秀的性能监控平台。为什么我们要使用性能监控呢?并不是为了炫耀我有多么酷的玩具,仅仅因为我们希望在问题发生的第一时间就能知道。在第一时间发现问题,把问题解决于无形之中,总比出了大麻烦通宵达旦加班舒服得多。然而有的人喜欢说:“有些问题留着也不会有什么影响。”,但我觉得服务端的事情,
凡是冒烟的地方,终究会着火的。
还有的人喜欢说:“我的代码绝对不可能有bug”。不过这只是吹牛逼。
废话不说了,直接上干货
OneAPM的监控服务主要分以下几块Application Insight 应用程序监控
Browser Insight 浏览器客户端监控
Mobile Insight 移动客户端监控
Cloud Insight 云服务器监控
使用 OneAPM 监控自己的项目,首先你需要去 oneapm.com 注册一个开发者账号。
Application Insight 应用程序监控
登录平台以后根据自己项目的语言选择探针,我这里项目是用的 express,所以选择了 node.js,在 OneAPM 里面对怎么安装探针写得很详细,大概就是在项目的目录下运行
npm install oneapm --registry http://npm.oneapm.com
然后配置文件从
node_modules/oneapm里面拷出来,改一下
License Key,就这么简单。
我们安装好探针以后,过几分钟让插件收集到数据,就能在面板里面看到各种图标。
首先需要关注的是响应时间图表
这个图表会对服务端耗时给一个大体印象,大家可以发现我们项目最慢的时候,是发生在8月18号晚上左右,有请求大约1.25s才结束。紫色的占了绝大多数,
这些都是外部服务消耗的时间。
右上角的窗口叫做 apdex
这是一个评估用户满意度的指标,从这个指标可以看到用户是否满意我们的响应速度,最右上角有 1[0.5] 可以看到我们 100% 的用户都满意我们的响应速度,小于0.5秒的请求,
我们称之为满意。我们这里是用的 OneAPM 的默认设置,小于0.5秒表示满意,0.5-2秒是可容忍,
2秒以上则不满意。
cpm 图表
这个图表代表吞吐量,我们可以看到项目最高的时候,大概每分钟80次请求,平均每分钟17.88次请求。Web 事务图表
这是一个很重要的图表,在这里我们能看到性能最差的几个 web 事务,我们通过 url,能找到代码中对应的
controller函数,从而找到这个接口中性能的瓶颈
我们来仔细看一个请求吧,第一条
express/POST/api/ex…
(鼠标放上去可以显示全部的url, 实际上这一条是这样的
Expressjs/POST/api/exams/signup-all)
我们可以点进去,查看接口的详细情况。
里面有一些仅对这个接口的吞吐量,执行时间等等的图表,具体含义和前面介绍的差不多
,只不过考察的对象变成了唯一这一个接口。
我认为最重要的一个图表是 breakdown table
这个图表反应了我们这个接口对外部应用(external),数据库(database)的调用情况。从图表上可以发现,每次我们调用这个接口,我们会调用37次一个叫做xxxxxtct.com是http协议的
外部服务。执行的时间占到了96.88%,另外查了2次数据库。分别占0.49%和 0.07%
看到这里,咱们就知道怎么优化啦~~拿我这个接口来说,这里的瓶颈主要是卡在发送37次http请求给
xxxxxtct.com这个地方,这个xxxxxtct.com其实是我们自己的一个子系统,如果我在子系统里面
写一个接口,把现在37个请求的内容合并,这个性能问题就完美的解决了。
另外 OneAPM 的 Application Insight 还给我们提供了,系统拓扑图,按 web 事务查找瓶颈的功能,按 sql 查找瓶颈的功能,
外部服务的具体执行时间(这个很重要,看谁在拖我们的后腿)以及后台服务的监控。
最后说一下错误率这个 table,这是我个人的经验
express 在抛出系统异常的时候,有可能会挂掉。下面举2个栗子exports.show = function(req, res) { a.b //a == undefined }
抛出异常
exports.show = function(req, res) { request.post({ url: xxx-service.com }, function(err, response, body) { a.b //a == undefined }) }
抛出异常,然后服务挂掉。
OneAPM 是被 express 程序启起来的,算是 express 进程的一个子进程,如果 express 挂掉了,
OneAPM 也跟着挂了,所以,不可能有机会发回错误信息。
结论是只要在回调里面抛出的异常,任何探针都没有办法收集到错误,
因为在这一层无法做这件事情。
当然,我们虽然有 pm2 这样优秀的进程管理工具来帮我们,挂掉之后自动重启服务。。。
但我们需要在第一时间获得报错信息啊。。。。即使 pm2 的 error.log 里面会保留异常,
但谁又会没事专门盯着 error 这个日志看呢。
针对这个问题,我自己写了一段代码来收集错误日志,希望对大家有帮助。
var pm2 = require('pm2'); var Slack = require('slack-node'); pm2.launchBus(function(err, bus) { console.log('connected'); bus.on('log:err', function(data) { var webhookUri = "{你的slack webhook}"; var slack = new Slack(); slack.setWebhook(webhookUri); slack.webhook({ channel: "#general", username: "cq-tct", icon_emoji: ":ghost:", text: data.data }, function(err, response) { console.log(response); }); }); });
把这一段保存为
err_notifier.js放在项目根目录下,每次启完服务之后运行
node err_notifier.js
这样就能通过 slack 第一时间收到报错了。即使服务挂掉也能发过来。
这里用了另一个叫做 slack 的工具,slack 是一款即时通信的办公协作工具,相信大家或多或少都听说过
(就是创业半年估值11亿美元,一年变28亿那个家伙)。国外类似的还有 hipchat,国内我不太清楚。
首先去 slack 申请一个 team, 然后创建一个 room,为 room 打开一个 webhook,
把 webhook 的地址赋值给 webhookUri, 这样我们无论在哪里,只要项目报错,就能第一时间
收到通过 slack 推送过来的错误日志。
当然,你可以把推送的工具改成,hipchat,邮件,短信,这个随大家高兴了。
关于 pm2 的 event monitor,还有更多事情可做,大家可以参考这里
https://github.com/xiaoyang2022/PM2/blob/dadf0f5806536ae95636ac929155c39b8bf030bb/doc/PROGRAMMATIC.md
最后
OneAPM 虽然可以帮大家在开发初期铺平道路,但也不意味着因为有了监控就可以胡作非为(反正项目只要冒烟了,OneAPM一目了然)。
我认为最靠谱的做法是:严格遵守各种 style guide 来写代码 + 一个监控系统 + 100% 覆盖率的单元测试 + 几套集成测试 + 一套可靠的发布流程
本文系国内 ITOM 行业领军企业 OneAPM 转载自 cnode 社区。想阅读更多技术文章,请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
相关文章推荐
- 浅谈 OneAPM 在 express 项目中的实践
- 定制RPM包并加入内部Yum Server
- 「产品经理」和「功能经理」的区别
- 移动互联网公司如何将BPM流程管理变身移动化?
- 当产品经理遇到了研发总监,搞不清楚了性别!
- 移动互联网公司如何将BPM流程管理变身移动化?
- 视频播放MPMoviePlayerViewController
- 谈谈自己对REST、SOA、SOAP、RPC、ICE、ESB、BPM知识汇总及理解
- 简易web服务器(npm)
- pm命令
- npm老不行?用淘宝的服务器的源吧
- rpm包卸载时error: specifies multiple packages
- MySQL 服务无法启动。 服务没有报告任何错误。 请键入 NET HELPMSG 3534 以获得更多的帮助。
- Pixhawk源码笔记一:APM代码基本结构
- 给客户创建IPMI帐号:
- BZOJ3439: Kpm的MC密码
- Start Xamarin——与Microsoft 的sales development manager的闲谈
- Setting up Intellij with CyanogenMod/AOSP development
- rpm包和源码包的一些相关知识
- GDALWarp设置GDALWarpOptions::dfWarpMemoryLimit过大时处理失败