云监控部署与试用体验

云监控部署与试用体验

虽然都在不同的公司，做着不同的业务，但是大多运维总会经历相同的故事，以及背着类似的黑锅。运维们大多有如下经历：

什么是 APM ?

为什么要使用 ？

分别从两个层面考量，分别为运维层面与代码层面

运维层面团队规模小，大多数团队因为成本问题，都由开发人员兼职，造成了没有专业运维的一个局面，导致无法做更多的运维层面监控。代码层面运维能监控到众多系统层面甚至业务级别监控，但是代码级别、终端用户层面无法监控到。部分 App /程序上线初期因为用户量较少服务器能够顶住，但是一旦用户上来，将会变成乱成一团，最终导致用户流失。

六个监控大项

共有六项功能，接下来我一一使用，并对它和传统的开源监控来做比较

可监控 Java、.NET、Node.js、Python、PHP、Ruby 性能，通过探针的方式监控，可以监控到代码层面的性能，例如代码响应时间、吞吐量等等，研发人员通过它可以快速的定位性能低效代码

通过Ai方式注入或者流量器中增加js ，js 收集浏览网页用户的信息，并提交到服务器。于是，我们能够了解到真实用户对网站的浏览情况。例如：白屏时间、首屏时间、脚本错误、网页加载就绪时间、各种浏览器的访问情况，甚至能了解不同浏览器、运营商、地区用户的访问状况。

与Ai相类似，唯一不同的是它属于用户层面软件管理，真实反馈用户是用情况，并定位到代码问题。目前支持 iOS、 Android ，Windows Phone 用户量毕竟太少

服务器系统级别监控，主要监控CPU、内存、网络、硬盘等基本信息

正式试用

因为运维生存时间是 LNMP 环境，所以接下来的内容以 LNMP 为主，当然尽量试用更多的业务

试用之Ai

其实就是安装一个 PHP 扩展，而且官方已经列出了傻瓜式的文档，所以可以知道安装到底有多简单了。极力推荐官方改成一键安装方式。

安装 PHP Agent

在提示输入「License Key」时，输入「License Key」

BwQCBwAPDAd5724VHAhDXw9NW04886BbXhgGCAkDTb0f6wBfGwNRTQcE3ca5BgcZBAAVBls=

等待安装脚本执行。若出现以下信息，则安装成功。

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毫秒。看到这些数据，心里有底了。

吞吐量

每分钟平均请求量

目前这边每分钟平均27.17个请求，上图图层显示的数据为14：50到14：52两分钟内平均响应时间328.76ms，执行次数66次。如果吞吐量小，响应时间长，那应该引起足够的重视，将问题消灭在萌芽期。

Web 事务

由此，我找到 Uri/wp-login.php 在整个过程相对耗时间，这是一个较少用到的页面，从上图可以发现2分钟内只执行了2次，平均响应时间却达到995.78毫秒。

运维生存时间时间启用了酷炫的登陆页面，后台图片为 bing 的背景。这个文章竟然是通过 filegetcontents 抓取的，得不偿失呀！

Web 事务追中不仅仅包含了代码级别追踪，其中还有请求参数，SQL 语句。功能酷的不能在库了。到底是 SQL 有问题还是代码有问题， 都给你展示出来了。

错误信息

程序执行过程中可能会少量出现错误，因为概率的关系，我们可能无法遇到，有些错误致命，有些错误无关大小， 也就能抓住他们，等着开发人员去消灭。

以上错误，在近6小时出现1326次，庆幸它是一个 warning 。为此功能点赞！

试用之 Bi

试用Ai之后，即使它是商业化产品，但是崇拜之心油然而生，毕竟这些功能 Zabbix 、NAGIOS 无法实现。Bi , 浏览器应用管理，适合门户、论坛等站点，数据均来自真实用户，能够最直接的了解到站点性能，以及用户端出现的错误。

有三种部署方式

复制/黏贴 js 纯文本输入应用名称后，复制生成的代码，将其粘贴在中。注意：需要将代码粘贴在 后面，所有