【编者按】OneAPM 运营团队，近日在 github 上发现了一篇文章，特别奉献给大家。本文作者王宇先生从2015年年初就开始使用我们的产品，也是OneAPM 的忠实用户。
OneAPM 是一个优秀的性能监控平台。为什么我们要使用性能监控呢？ 并不是为了炫耀我有多么酷的玩具，仅仅因为我们希望在问题发生的第一时间就能知道。 在第一时间发现问题，把问题解决于无形之中，总比出了大麻烦通宵达旦加班舒服得多。
然而有的人喜欢说：「有些问题留着也不会有什么影响。」但我觉得服务端的事情， 凡是冒烟的地方，终究会着火的。
还有的人喜欢说：「我的代码绝对不可能有 bug 。」不过这只是吹牛逼。
废话不说了，直接上干货吧。
OneAPM 的监控服务主要分以下几块
- Application Insight： 应用程序监控
- Browser Insight： 浏览器客户端监控
- Mobile Insight： 移动客户端监控
- Infrastructure Insight： 服务器监控
使用 OneAPM 监控自己的项目，首先你需要去 OneAPM.com 注册一个开发者账号。
Application Insight 应用程序监控
登录平台以后根据自己项目的语言选择探针，我这里项目是用的 express，所以选择了 nodejs, 在 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 的 errpr.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，还有更多事情可做，大家可以参考这里
最后
OneAPM 虽然可以帮大家在开发初期铺平道路，但也不意味着因为有了监控就可以胡作非为 （反正项目只要冒烟了，OneAPM 一目了然）。
我认为最靠谱的做法是: 严格遵守各种 style guide 来写代码 + 一个监控系统 + 100% 覆盖率的单元测试 + 几套集成测试 + 一套可靠的发布流程。
写在最后：OneAPM 非常感谢王宇先生对我们产品的支持，未来我们将更加努力，为用户提供更大的价值。
版权声明：本文为博主原创文章，未经博主允许不得转载。