好雨云资深架构师祁世垚参加Qcon演讲，现场反响热烈
好雨云资深架构师祁世垚参加Qcon演讲，现场反响热烈
4月23日下午，好雨云资深架构师祁世垚参加了Qcon运维与监控专场，并发表了主题为《实时分析在业务监控中的应用》。
在自我介绍之后，他谈到了好雨云，他表示，好雨云平台是为了解决复杂的服务器管理问题，为创业者、开发者、企业提供快速开发、部署、运行、伸缩任何应用的云平台。
对于监控的目的，祁世垚认为主要有两个方面：
1.系统中的各类服务是否真正在高效地运行
2.何时该扩充资源，已有资源是否充分利用
那么，为什么要引入实时分析呢，祁世垚表示，目前的系统级监控的参考价值不够，系统层级的监控工具有很多，虽然可以追查到过去某一时刻的系统状态，但无法追溯当时的业务状态。
- CPU利用率高
- 磁盘读写量大
- 网络流量大
而常规的统计方法，人工维护变化大，成本高，掩盖了很多问题。
如何解决呢，祁世垚认为主要在四个方面下功夫：
- 开发优化代码
- Dba优化数据库
- 优化其它后端服务
- 扩充资源
之后，他谈到了实时分析能实现什么：
- 在时间故障点快速确定问题来源
- 发现不合理的请求
- 找到可能成为隐患的问题点
- 对接报警系统，丰富监控项
那么好雨是如何实现的呢，借助复杂事件处理方式（CEP，Complex Event Processing），好雨云为用户提供了实时的 Web 请求性能分析以及数据库 DML 操作性能分析，能够观察到业务变化对系统的影响，能够在最短时间里发现问题点，在问题放大前将其解决。
附上祁世垚的现场演讲实录：
非常感谢大家下午还能坐在这儿听精彩的演讲，第一位演讲讲师是来自于好雨云的系统架构师祁世垚。我们为什么要设置运维与监控专场，主要是提供业务监控、性能管理这种企业现在比较多，而且需求量也比较大。针对这种大的趋势，我们设置了运维与监控专场。目的还是希望所有的参会者都能够学到系统运维、业务监控相关知识，不管以后在工作上，还是在企业决策上都能够对你们有所帮助。
今天下午有三场演讲，分为实时分析、应用性能管理和微服务架构，我就不再继续解释了，接下来欢迎来自于好雨云的祁世垚给我们分享“实时分析在业务监控中的应用”，掌声欢迎。
祁世垚：谢谢大家，我叫祁世垚，来自好雨公司。我今天分享的是实时分析在业务监控中的应用，过去几年我和我的团队通过实时分析解决了很多生产环境中的问题，在此过程中的经验、心得将拿出来与大家做一个分享。
先做一个简单的自我介绍，我是好雨联合创始人，现在主要负责好雨底层架构设计。我这边需要给大家科普一下好雨云是做什么业务的，我们是基于docker做平台部署的，有共有云平台，私有化部署。支持构建代码里的常用语言，用户可以自己通过docker来自己编译一些代码。持续交付，品太上已经为大家提供了生产环境、测试环境，还有开发环境的一些部署流程。第三个特性是资源的快速伸缩，资源伸缩起来非常快速，几乎是秒级，就能很快把一个资源扩充到20个点，或者想扩多少个点都可以。在伸缩的时候，计费也是实时的，只按照你使用的资源量来计费，从而实现很高效的运维。运维底层是高可用实现，运维这边需要关注的一些点就少了，可以去分析更高的事物。这边提供了业务级的监控，就是我下来主要要讲的。
我们做业务监控是出于什么目的？传统的监控我们可以看到系统里面使用的性能值，但我们并不知道业务使用的情况，使我们这些服务是否是在真正高效的运行，我们也并不确定是否真的需要去做资源的扩充等等，我们当前的资源是否有真正的充分利用。
为什么需要做实时分析呢？比如说系统级监控，我们觉得一个常规系统级监控参考价值已经不够了，比如说一台机器CPU几乎跑满，磁盘的读写量也很大，网络流量也很大，但这个时候我们并不能说它是有问题的，很可能它的业务量就要跑这么大，程序优化的也特别好。但是我们不能说它是没有问题的，其实它就不应该跑这么多资源，这些我们从传统的系统监控并不能判断出来。
我们可能会做一些基础的业务监控，比如说网站的QPS、频率响应时间，在线人数等等，一般是用一些脚本，分析日志来得出，这里面的变数比较多，人工维护的成本太大，而且可能一些真正的问题就被掩盖住了。我们对一些系统中出现的问题总是后知后觉，这是做响应时间和吞吐率的历史趋势。先看上面这个，这是过去一个小时内响应时间的变化，我们看它有两次很大的峰值，在这两个峰值处到底是谁导致它变慢了？应该怎么找？一般是用日志来找，但找的时候总是比较耗时间。
另外吞吐率的变化，前半段有两个很大的抖动，这个时候是哪些请求突然变高了，这些我们也不得而知。如果我说变高了的请求是有问题的，响应时间如果突然变大了，对我们网站来说有非常大的影响。
比如说我们找出了有性能问题的代码，我们该如何去解决？首先开发它需要在程序逻辑这一块处理，看有没有问题。另外就是交给后端服务，比如说数据库，还有其他服务，实在不行就做资源的扩充了。但是如何去优化这些后端服务？以数据库为例，传统的话可能会对数据库在服务层面做一些优化，用第三方优化过的版本，根据自己的业务去调整一些数据库的参数，或者说提升数据库的硬件性能，或者说再做逻辑上的一些拆分，比如说垂直分割、水平分区。做这些的同时，也需要真正停下来想一想，我们做这些事是想办法能提高单个实例的处理能力，但是要想想是不是真的要承受这么大的请求量，这是我们需要对SQL的请求做一些判断分析。
当前这些后端服务的使用情况我们不是很清楚的，它里面都是黑盒的，常规的监控工具又不够用。比如说一些开源的工具仅仅是监控书数据库的数量，一些参数值的变化。但我们想知道的是，在这里面业务对应SQL的请求到底是什么样的，这是我们需要有工具来查看的。另外是否真的需要去扩充资源，如果我们业务去请求数据库，或者请求别的服务，它是有性能的问题被掩盖住了，我们单纯的去扩充资源，仅仅是把问题给忽略了，忽略了这个问题一直没有被解决，这次扩吹完了之后，下次资源可能很快就要到达了，这样就会有很多的资源浪费。
这时候我们就需要衔接运维和开发之间的沟通，运维发现传统系统级的使用之外，还需要了解我们是否真的要承受这么多的请求。开发这边上线以后，对它使用底层各种服务的情况，需要知道有没有问题。但运维这边现在也没有工具提供给它，所以我们这一块是开发一套工具，然后来提供一些依据供运维和开发共同分析的。
影响性能的可能有好几点，举一些例子，常规的URL，在高峰请求数量给变大了，对运维的压力会造成影响。但是有些URL很多，但是真的需要这么多吗？业务逻辑上使用有没有问题？我们需要知道。还有有些数据库的查询有没有真正的被缓存到cache，这只有开发知道，数据库运维是不知道的。另外是该分离到从库的CQL有没有分离也不知道，还有一些cache缓存被穿透了，压力也被丢到数据库这一层了，然后是一些静态资源未压缩，可能会造成带宽的占用和浪费。
我们运用实时分析会发现什么问题？我们在出现故障的时间点能快速确认时间来源，能确认它到底是不是这方面的问题，如果不是，我们马上到别的地方去查找。在发现一些不合理的请求，可以根据具体的案例分析，找出一些可能成为隐患的问题点，尤其用普通日志分析的工具可能就被掩盖了。用事实分析可以处理一些平时用的手动监控脚本实现不了的功能，这样能丰富我们的一些监控项。
这是我们的一个例子，我们网站为用户提供的实例，是这么一个功能。我们统计过去5分钟内占用时间最多的URL，这是把URL按照累计时间来排序。累计时间是按照平均响应时间和它的请求次数的乘积算出来的。这样我们能发现什么呢？就能发现排名考前的URL是当前系统占用资源最多的，它的使用情况有没有问题呢？我们可以列出来看一眼。比如说第一个，它的请求数量不多，但是响应时间要稍慢一点，200多毫秒。但是200多毫秒是不是合理的？需要让开发去看。
比如说第三个，请求响应时间是很快的，但是它的频率很高。如果说在高峰期的时候会不会又变得更大，它也是影响性能的一个地方。另外我们的业务请求可能在每天的时间点都会有对不同业务的请求，所以这个图在各个时间段，能浮现出来的问题是不样。这个图页面每隔5秒能定时刷新一下，过去5分钟内最新的统计结果。
在说URL性能比较快，但是请求量比较大的问题，会造成什么样的后果。举一个比较极端的例子，比如说一个请求要调用cache的，调数据库的，或者别的。里面如果实现的不太好，可能去请求一个资源的时候，他还占用着别的资源的连接，如果说他这时候出的问题，可能别的资源还没有被释放，这时候其他服务去申请资源就出了问题，这样的话我们看的是因为不相干的问题，比如说数据库慢了导致了cache那边出了问题。
我们还做了数据库SQL的占比分析，也是按照数据库SQL请求的平均时间跟请求个数做累积，做排序。第一次做出这个监控图的时候，发现排在第一的，或者前几个的特征是这样。它的平均响应时间都是在慢查询的罚值以下，所以不会出现在慢查询的日志里，但是它确实会占用很多数据库的资源，请求量非常大。如果我们不用这个工具是发现布不了，等发现的时候也是几个月以后，数据量更大的时候变得越来越慢，超过罚值的时候我们会看到漫长行为有很多很多的请求，这是在解决问题的时候已经有一些影响的。
我们再按照这个图上的示例去说，比如说第一个是对数据库做更新，做写入的操作。我们根据具体的SQL去看，发现它是对每一条的数据都要做一次更新。这时候我们可以想一想，如果这样会造成很多的数据库的写操作，这时候我们就要跟开发区沟通，是不是开发逻辑有问题，是不是把更新操作能变得更少一点，有了这个工具，我们就可以以此为凭据，跟开发确认一下有没有什么问题。另外我们发现有很多比较快，但倾斜量比较大的查询，看了也没有问题。但是我们也需要去确认一下，他这个业务的场景在哪儿，是否可以被做cache，是否可以被缓存到从库等等。或者更上一层，我们可以在产品方向看一下占用系统资源如此多的SQL，对公司的一些产品价值有没有意义，说不定从产品方面我们就把功能给砍掉了。
这边是案例的一些分享，首先我们也对Memcache的请求情况做了一个分析，这边我们是统计了Memcache次数的排行榜，我们第一次做这个图的时候，做出来前没有想到会出现那种很异常的情况。比如说我们get一个key，它是不成功的，大小是零，因为它从Memcache里面没有查到数据，就说明它会把请求甩给数据库查询，这是有问题的。
我们还看到有另外一个图，是（英文）操作的值也是空的，虽然它请求去缓存了，但是缓存了一个空的值，这种空的值也还是不可能被get到，或者根本就没有做get的请求。然后是一些没有意义的请求，比如说一个key在这边做了一次（英文），又做了一次get，几乎是一对一的关系，这边做缓存几乎没有意义，何况我们能找出相关的key，去确认它的功能。
讲一下我们是如何这方面的功能的，我们使用了一套复杂事件处理的概念，这主要是来通过处理大量的事件流，通过匹配复杂的模式来分析出结果。我们这边是用它的一个开源来实现的，是一个Java写的Esper是基于内存来计算，性能上是非常高的，能达到每秒钟处理100万个事件数量。
一个简单的流程图是这样的，我们会把Weblog，前端过来的用户请求日志抽取过来，数据库SQL查询的请求也给取过来。比如说Memcache等等的，还有在程序这边来生成的一些事件。中间通过一个传输层交给Esper统计分析，我们根据写好的规则统计处结果，结果可以通过用Web（英文）来推到前端来看，也可以到终端上用命令行来看，这对运维比较好，还可以对一些结果做报警，或者把这些结果记录下来，供回溯来看。
然后讲一下事件是如何抽取的，Lblog是实时监控web的日志做格式匹配，抽象成一个事件。数据库相关的工具，比如说Mysqlsniff，mongosniff，以及对key的使用情况也会做一些日志。比如说这样，这里面大小是3，1是成功等等，第二行get是成功的。下面还有一些别的操作，我们都是对日志的格式做一些匹配，把它抽象成一个事件。抽象成一个什么样的事件？比如说URL，事件的主题可能是URL可能是SQL，也可能是请求的key，一般URL和SQL会包含两个元素，比如说包含消耗时间和返回的大小，和它具体的动作。还有一些别的扩展的属性，其实就是一些（英文）。
这个事件交给（英文）这边先做了一个映射，把MySQLDRM语句定义了一下，有如下属性，java、sql、action、time、size、group，前面我们说了一个功能是想看有些SQL是否分到了从库上去。我们可以通过一些语句，比如说我们是通过交易库主库看，先建一个交易库主库的window，下面是第一个从库的window。这边看上面的语句，有个.wintom60秒，这是很独到的概念，有一个窗口只保留过去60秒的事件，在此基础上再做一些分析。
这边有之前做过的一个图，这个窗口是一个长度为5的窗口，这个窗口里只能从最近的五条数据来看。如果是.win五秒的话，可以看最近五秒的数据。如果来了五条数据，会一个个都存在里面，但是当第六个事件过来，会把第一个事件挤出去，这样查最近的数据。
接下来会做SQL的运算及分析，这是我们从交易的主库里面去按SQL来查询，查询每个SQL整体的响应时间，平均的响应时间，是哪个SQL哪个动作还有它的总数，做排序，每隔5秒钟去统计一次，这是出现了最简单的一个范例。
再回过头来讲我们遇到的一些其他问题，Memcache这个讲完了，接下来是Ajax定时请求，我们通过请求频率来发现有那么一个URL，每隔一分钟，有那么一两秒的变化。像网站上整体上没有问题，但是在高峰期的话会造成一些阻碍，我们就去分析它的业务功能，看它是否能把请求的频率给降低，确实给降低了，它只需要每隔5分钟去请求一次。后来我们又把它这个形式给转换了，用web服务的方式来解决，从而降低web服务器的问题。另外一个案例是，有一天我们观察了一个URL请求逐渐变慢，平时请求时间也就是5毫秒内，每隔一个小时就上升了2毫秒，这个问题我们没有特别的关注，直到晚上涨到20毫秒的时候整个网站就崩了，因为是它拖垮的，像后端的一块服务。如果说这个工具能帮我们去发现一些变化，有异常的变化，观察到的同时还要能关注它，重视它。
下一个案例是发现机房的流量暴涨了100兆，CDN的流量也是涨了300兆。我们这边就来分析，就立刻写了一条语句分析URL，按照大小来排序。也就是说每个URL整体占的请求的时候，返回数据包大小的和是最大的，弄完成马上就发现，排第一的总量是第二的几乎20倍，我们能看到URL是一张图片，这个图片发现是新业务上线的时候没有做压缩导致的，这些问题可以很快的得到解决。是恶意抓取的，用户可能会做一些伪装什么的。这边通过对用户做一些汇聚，然后就找到了带这些（英文）头的IP，认为有抓取的嫌疑，随时能把他们给屏蔽了。另外有一次是防住了一个不能算太高明的Ddos攻击。还有一个URL同时被IP访问，量很大，排在了最前面，这样处理起来比较简单，直接把URL的请求给屏蔽了，就解决了这个问题。
主要内容就讲完了，这一块的产品我们打算近期做开源，大概3个月之内，如果大家对这个产品感兴趣的话欢迎大家扫一下我们的公众号，或者加个人微信，我们可以再交流。
主持人：谢谢祁老师。
嘉宾：您好，我有两个问题想请教一下，第一个问题是我听了您这个报告，发现大部分的监控还有数据分析都是基于服务端的，或者是云平台这一端的性能数据。我想问一下你们这边有没有端到端的性能，因为端到端的性能还要受客户运营商、网络性能的影响，你们有没有对这个进行监控和处理？
祁世垚：端到端的有日志能记录一下它的请求主体响应时间，有单次请求的结果，能生成这样的数据，我们是能做分析的。
嘉宾：需要客户自己生成日志是吗？
祁世垚：对，需要客户自己定义生成事件。
嘉宾：您列了访问最多的URL，倒叙排的。我们知道URL里面是可以含有参数的，这里面是不是针对整个URL去做聚合？如果是这样的话，有参数的URL就被认为是不同的URL是吗？
祁世垚：因为参数是可变的，我们就把参数的值给替换了，这里面把参数值给替换成百分号了。
嘉宾：就是先要识别URL的参数字段再去掉，那现在有URL（英文），这样参数可能不能通过简单的问号后面就是参数预定义的规则识别出来，这样的话有没有什么好的办法把它聚合在一块呢？
祁世垚：这要看各个公司具体URL的格式，来分析里面的格式，每个公司不太一样。有些是（英文）形式的，参数都是在URL的主体里面，这时候需要来抽取日志的程序，加一些对特别的地方的处理，做特别的匹配。一般像这种URL的话不太多，都是很像的。
嘉宾2：我是工商银行的，老师我问您一下，刚才您说是实时分析，这个对应用性能影响大吗？
祁世垚：这个分析都是异步的，像web的请求会基于日志，我们是来分析它日志的，把日志做抽取、转发，MySQL的话是对网卡做工作，自己已经实现了异步，不会因为对服务端做抽取来影响工作，尽量不对服务端造成影响。
嘉宾3：您监控这一块的架构好像取舍非常明显，现在主流的API后面都挂一个（英文），像通过日志分析的都用ELK来做，为什么我们现在决定以SQL为主，我发现实时分析结果比较容易，你是不是没法通过埋点的方式确定恰恰这一块出现了问题。
祁世垚：我们的维度不太一样，这个维度是想知道未知点在哪里有问题，如果ELK的话应该根据一些查询的条件，找一些特定条件下使用的情况。但是如果我们不太确定这个条件是什么的话，我们需要用这套工具，自动找出当前是谁影响最大的。
嘉宾4：从日志来监控的话，比如说SQL做全量监控，对IO的压力会非常大，这个问题怎么解决呢？
祁世垚：这边像程序的话，就在程序例加一些抽样，通过这种方式来判断一下。
嘉宾4：抽样会不会不全？我一个批量的数据里抽样的可能是没问题的，而没抽样的可能正好出现问题了，这种怎么来做一个比较好的解决策略呢？
祁世垚：据我们实践中的经验来说还没有碰到这种问题，因为单个实例上拆分的比较多，单个实例压力请求不会那么大，如果将来再更大量级的话确实会有一些问题，这一块我们确实需要在更大的环境上试，会把系统做的更分布式一些。
嘉宾5：你刚才说ERK可以搜索位置条件，你们这套系统如果比性能，跟ERK做对比的话，哪方面比较好？
祁世垚：最大的特点是在内存中做计算的，只是统计了他最近一段时间的，所以说它处理的数据量也不会很大。
嘉宾5：你好像都是设了一个定时的点，5秒查询，这是固定的点？
祁世垚：这个是可以自己改变的。
嘉宾5：你们现在是5秒？
祁世垚：对。
嘉宾5：为什么设5秒呢？当时是怎么确定的呢？
祁世垚：也就是在视觉上。
嘉宾5：ELK有个时间去选择，可以定点去选择，我感觉你们当时肯定也考虑了很多，我很想知道这5秒是怎么得出来的。
祁世垚：我们选时间段，刚刚那个例子里是滑动的去统计，每隔5秒去统计一下，是一个块，这个窗口设计的时候就是最近的一个窗口。
嘉宾6：我想问一下，您刚才提到的是一个抽样的区域采取数据，还有实时用内存去算监控，我觉得可能会遗留两个方面，可能中间数据会遗留，或者过去的点会出问题，这个系统怎么处理呢？以前出的问题，或者中间哪个点出现的问题是怎么覆盖到，能够分析到出现问题的原因的呢？
祁世垚：我们是看当前有什么问题，这些图都是在当前分钟内有哪些问题的。
嘉宾6：有的问题出问题就是以前的问题，有些你当时知道不了。
祁世垚：分两种，一种平时我们看到在业务比较高峰期的时候，会打开这个工具看一看，看有哪些有隐患的点。另一方面如果发现在过去有问题的话，像统计的结果都有日志的记录，我们可以再回溯看到底是谁有问题。
主持人：谢谢祁老师这么耐心的回答，还有问题的话大家可以到203E找祁老师继续沟通，谢谢。