作为 Zabbix 骨灰级粉丝，一直以来对第三方监控（APM）都是拒绝的。一来觉得收费，二来担心数据被人所知，三来觉得 Zabbix 牛逼到无可取代。但是，随着 APM 市场的火爆，我决定「放下身段」试用一次，并且会总结出它与开源监控之间差别在哪里。
运维经历的磨难
虽然都在不同的公司，做着不同的业务，但是大多运维总会经历相同的故事，以及背着类似的黑锅。运维们大多有如下经历：
- 网站或者业务访问不了，服务器问题，运维的责任
- 昨天还好好的，今天就出现的问题，运维的责任
- 部分地区用户反馈网站/App 无法试用，运维查查服务器。而且这种问题大多出现在事后。
- 各种程序都需要监控，常见的 MongoDB 、 Redis 、 Nginx ，还会出现各种不常见的应用。任何一种软件都要熟悉，运维总是在不停的学习，待遇缺一直比不上研发！
- 服务器出现问题，老板找运维、领导找运维、开发也找运维，运维并不知道代码逻辑，看日志，各种排错。
初识 OneAPM
OneAPM 是一家为企业和开发者提供 APM 解决方案的服务商，支持 Java、.NET、PHP、Ruby、Python、Node.js、HTML5、iOS、Android 等语言和操作系统。
什么是 APM ?
既然试用 APM ，我觉得很有必要给大家解释一下这个名词。应用性能管理（Application Performance Management）主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本 (TCO) 。使用全业务链的敏捷 APM 监控，可使一个企业的关键业务应用的性能更强大，可以提高竞争力，并取得商业成功，因此，加强应用性能管理（APM）可以产生巨大商业利益。国内外的 APM 有 Compuware 、 iMaster 、听云、New Relic、OneAPM 、AppDynamics 等。 解释比较干，如果还是不了解什么是 APM ，那么请随我全面试用 OneAPM 的过程来了解什么是 APM 。
为什么要使用 OneAPM ？
分别从两个层面考量，分别为运维层面与代码层面
- 运维层面 团队规模小，大多数团队因为成本问题，都由开发人员兼职，造成了没有专业运维的一个局面，导致无法做更多的运维层面监控。
- 代码层面 运维能监控到众多系统层面甚至业务级别监控，但是代码级别、终端用户层面无法监控到。部分 App /程序上线初期因为用户量较少服务器能够顶住，但是一旦用户上来，将会变成乱成一团，最终导致用户流失。
OneAPM 六个监控大项
共有六项功能，接下来我一一使用，并对它和传统的开源监控来做比较
可监控 Java、.NET、Node.js、Python、PHP、Ruby 性能，通过探针的方式监控，可以监控到代码层面的性能，例如代码响应时间、吞吐量等等，研发人员通过它可以快速的定位性能低效代码
通过Ai方式注入或者流量器中增加js ，js 收集浏览网页用户的信息，并提交到OneAPM服务器。于是，我们能够了解到真实用户对网站的浏览情况。例如：白屏时间、首屏时间、脚本错误、网页加载就 绪时间、各种浏览器的访问情况，甚至能了解不同浏览器、运营商、地区用户的访问状况。
Ai、Bi 都比较偏向于开发，Ci则偏向于运维，Ci提供对系统、开源程序（例如：Nginx、PHP、Apache、MySQL、redis 等等）的性能指标管理，而且也提供系统层面的基本监控，例如 CPU 、内存、硬盘，但是功能相对比 Server 模块弱一点。
与Ai相类似，唯一不同的是它属于用户层面软件管理，真实反馈用户是用情况，并定位到代码问题。目前支持 iOS、 Android ，Windows Phone 用户量毕竟太少
服务器系统级别监控，主要监控CPU、内存、网络、硬盘等基本信息
OneAlert 的前身是 110 monitor ，偏向于运维，它是监控中最终的一环。 OneAlert 是一个中心，任何告警信息发送至 OneAlert，你可以设置各种规则，例如什么时间点发告警给谁，通过什么发送发送，例如短信、邮箱、微信、app等等。此功能相对独立，不依托前面几 个产品。支持多种插件，例如zabbix、NAGIOS、阿里云，甚至竞争对手监控宝。不知道监控宝该高兴呢还是不高兴呢！
OneAPM 正式试用
因为运维生存时间是 LNMP 环境，所以接下来的内容以 LNMP 为主，当然尽量试用更多的业务
OneAPM 试用之Ai
其实就是安装一个 PHP 扩展，而且官方已经列出了傻瓜式的文档，所以可以知道安装到底有多简单了。极力推荐官方改成一键安装方式。
安装OneAPM PHP Agent
#wget https://user.oneapm.com/account/7e42e138b703a72ae6950531c9ad958a/agent/php/OneAPM_php_Agent_latest.tar.gz
tar -xzf OneAPM_php_Agent_latest.tar.gz
cd oneapm-php5-linux-install-script
./oneapm-install在提示输入「License Key」时，输入「License Key」
BwQCBwAPDAd5724VHAhDXw9NW04886BbXhgGCAkDTb0f6wBfGwNRTQcE3ca5BgcZBAAVBls=等待安装脚本执行。若出现以下信息，则安装成功。
OneAPM is now installed on your system. Congratulations!重启php-fpm
service php-fpm restart或者你是 Apache ，那么重启 Apache 就行了，等候几分钟，重新进入后台，便可以看到数据。
Ai 总览
默认显示最近30分钟数据。一一看下都有哪些功能及其作用 平均响应时间 分为4个事物， Web 事务、后台任务、数据库、外部服务，着重了解 Web 与数据库。
Web 事务响应时间为从接收到请求到放回之间的时间，最高平均值为870多毫秒，这个值可以容忍。好在运维生存时间时间有使用 CDN ，否则绝对都是无法容忍的。
数据库最大平均响应时间为3.08ms，执行次数16,316次，总时间50.22毫秒。看到这些数据，心里有底了。
Apdex （性能指数）
先来了解下什么是 Apdex 。 Apdex 是一个国际通用标准，是对用户体验满意度的量化值。 服务端 Apdex ：当前服务端设定的 Apdex T 值为0.5秒。这意味着响应时间小于0.5秒时，为满意状态，介于0.5秒到2秒之间为可容忍状态，2秒以上为不满意状态。 浏览器 Apdex ：当前浏览器设定的 Apdex T值为2秒。 这意味着浏览器加载时间在2秒内是满意状态，介于2秒到8秒之间为可容忍状态，8秒以上为不满意状态。
吞吐量
每分钟平均请求量
目前这边每分钟平均27.17个请求，上图图层显示的数据为14：50到14：52两分钟内平均响应时间328.76ms，执行次数66次。如果吞吐量小，响应时间长，那应该引起足够的重视，将问题消灭在萌芽期。
Web 事务
一个 http/https 请求从发起到收到响应这个过程，我们称之为 Web 事务。 有时候网站慢，有时候有正常，运维无法排查到问题。OneAPM 的慢事务追踪完美解决了这个问题。来找出运维生存时间网站隐藏的问题。
由此，我找到 Uri/wp-login.php 在整个过程相对耗时间，这是一个较少用到的页面，从上图可以发现2分钟内只执行了2次，平均响应时间却达到995.78毫秒。
点击如上连接，进入追踪
在最慢组件中，我们发现函数 filegetcontents 调用了一次，却执行了9秒时间。我们看看追踪详情，来探探究竟。 
运维生存时间时间启用了酷炫的登陆页面，后台图片为 bing 的背景。这个文章竟然是通过 filegetcontents 抓取的，得不偿失呀！
Web 事务追中不仅仅包含了代码级别追踪，其中还有请求参数，SQL 语句。功能酷的不能在库了。到底是 SQL 有问题还是代码有问题，OneAPM 都给你展示出来了。
错误信息
程序执行过程中可能会少量出现错误，因为概率的关系，我们可能无法遇到，有些错误致命，有些错误无关大小，OneAPM 也就能抓住他们，等着开发人员去消灭。
以上错误，在近6小时出现1326次，庆幸它是一个 warning 。为此功能点赞！
OneAPM 试用之 Bi
试用Ai之后，即使它是商业化产品，但是崇拜之心油然而生，毕竟这些功能 Zabbix 、NAGIOS 无法实现。 Bi , 浏览器应用管理，适合门户、论坛等站点，数据均来自真实用户，能够最直接的了解到站点性能，以及用户端出现的错误。
有三种部署方式
- 复制/黏贴 js 纯文本 输入应用名称后，复制生成的代码，将其粘贴在<head>中。 注意：需要将代码粘贴在 <meta> 后面，所有 <script> 前面。 优势：避免加载 js 探针第一个脚本引起的网络耗时和减少白屏时间。
- 复制/黏贴 js 链接 输入应用名称后，复制生成的代码，将其粘贴在<head>中。 注意：需要将代码粘贴在<meta> 后面，所有 <script> 前面。 优势：操作简单，部署方便。
- Ai 自动注入 Bi 探针 由 Ai 探针自动向前端页面注入 js 代码，只需简单配置，无需修改代码。 优势：和 Ai 无缝集成，可监控 Web 应用程序在不同区域、不同设备下响应时间，更新 js 探针方便
部署 Bi
使用 js 纯文本方式部署，输入应用名「运维生存时间 WEB」，保存即可获取到 js ，获取到的代码放到网站共用 head 之间。
如果不知道怎么放到 head ，联系对应的开发人员，他会告诉你。
在测试的前一周，我们已经部署了一个未上 CDN 的小流量站点，先用这个站点看看。
Bi 基本功能
功能分为：受访页面、Ajax、脚本错误、浏览器、地理、运营商。 这部分数据对前端工程师非常重要，白屏时间、首屏时间、网页就绪时间，OneAPM 统计了每一个 URL 的这些指数的平均时间，从中找出最耗时间的 URL ，对代码响应的改良。
Apdex 性能指数
此处能非常清晰的表现出当前站点的用户体验状况。如果大于2，那说明网站情况非常糟糕。如上截图，平均性能指标 Apdex 在0.28，可以容忍，看到这个指数心里相对放心，咱的站点用户体验不差。
脚本兼容性之脚本错误
公司有个前端工程师安装了各种浏览器，不知道的人还以为他爱好广泛呢，实际上他仅仅是为了在每种浏览器上做兼容性测试。浏览器有多家，每一家都有多 个版本， Firefox 都以及42.0了^_^。脚本错误在所难免， js 错误进一步导致网站部分功能无法使用。 OneAPM 记录了用户脚本错误信息，简直就是一个专业用户自动反馈（以往靠热心的用户的反馈，还提供测试，远程测试那得多消磨时间，而且其他未反馈的用户就别遗忘 了，被遗忘几乎等于流失）。 
如上信息可以知道哪个页面出现了哪些脚本错误，并且给出了用户信息、浏览器、错误信息、堆栈信息等。我想，前端工程师从这里可以解决相当多问题！
页面跟踪
某些页面慢，到底慢在哪里，和 Ai 的 Web 事务一样，提供了慢事务追踪。
点击需要 Trace 的页面，找到满加载追踪，资源为支持的可以 Trace
时间都在DOM
只列出了部分资源时序，底下还有更多，类似 firebug 的「网络」，显示各个资源加载所消耗的时间。但是功能略显不足，未显示每个资源 DNS 解析、建立连接、接收数据分别消耗的时间，但是它能为我们提供一定的参考。这边或许可以做得更好。
OneAPM 试用之 Ci
Ci 平台监控，具体干嘛的，我上一张图你就明白了。
用户只需在服务器安装 OneAPM Ci Agent，配置需要监控应用的配置文件即可。
部署OneAPM Ci Agent
点击设置添加平台，如下图
复制 shell 命令，在 Linux 中运行即可。
平台添加完毕之后，过几分钟就能看到信息
刚配置完毕，平台服务列只有 System 。 System 为服务器基本信息，例如 CPU、内存、硬盘、网络等。如下图
效果与刚安装完 Zabbix 一样，但是安装更简单，UI 更漂亮。
添加平台服务
有各种各样的程序需要做性能管理，例如 Nginx 、 MySQL 、 PHP 、tomcat 等
LNMP 环境部署
所有的配置文件均在 /etc/oneapm-ci-agent/conf.d/ ，支持被监控的软件都有配置文件 sample
配置文件如下
ll /etc/oneapm-ci-agent/conf.d/
-rw-r--r-- 1 oneapm-ci-agent root 2630 Sep 6 22:41 activemq_58.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 2619 Sep 6 22:41 activemq.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 232 Sep 6 22:41 apache.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 2372 Sep 6 22:41 cassandra.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 250 Sep 6 22:41 couchbase.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 916 Sep 6 22:41 couch.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 2408 Sep 6 22:41 docker.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 2385 Sep 6 22:41 elastic.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 1550 Sep 6 22:41 jmx.yaml.example
-rw-r--r-- 1 oneapm-ci-agent root 338 Sep 6 22:41 kafka_consumer.yaml.example
-