【编者按】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，还有更多事情可做，大家可以参考这里
https://github.com/xiaoyang2022/PM2/blob/dadf0f5806536ae95636ac929155c39b8bf030bb/doc/PROGRAMMATIC.md
最后OneAPM 虽然可以帮大家在开发初期铺平道路，但也不意味着因为有了监控就可以胡作非为 （反正项目只要冒烟了，OneAPM 一目了然）。
我认为最靠谱的做法是: 严格遵守各种 style guide 来写代码 + 一个监控系统 + 100% 覆盖率的单元测试 + 几套集成测试 + 一套可靠的发布流程。
写在最后：OneAPM 非常感谢怕孤单的热狗先生对我们产品的支持，未来我们将更加努力，为用户提供更大的价值。