|
2016中国应用性能管理大会CDN加速专场又拍云CTO黄慧攀题为《访问日志的大数据分析应用》的演讲，现场解读了在海量访问日志中提炼多个性能指标，对日志分析系统查询需求进行分析，对访问特点进行分析，并基于性能考虑对系统架构进行优化，从而达到优化CDN服务质量。
以下为演讲实录： 黄慧攀：谢谢，我是又拍云的黄慧攀，很高兴今天过来跟大家分享一下关于日志的大数据分析应用，这是大家平时都经常触碰的东西，不管是Web或者是Server，都会打日志出来，这是首先我们考虑的东西。然后打出来的日志到底有什么价值，这就是我们今天想跟大家分享的一个内容。 一、日志的价值
我们今天这个话题最主要会讲到日志，上图就是非常简单的一条。我们比起一般的会多了一些额外的信息，因为这是我们在CDN节点上面截取出来的，这里面包含一些我们的业务系统用到的做性能必要的数据。如果说只是很简单的去看这一段文字，我们根本不知道它是干什么的，它有什么价值也看不出来，就是一堆字符。但是我们需要对这些数据做结构化的理解，就变成下面这个样子：
你可以看到在这里面把每一个字段拆解下来，第一个肯定会看到客户端的IP，第二个是访问协议，还有访问的目标，URL、访问的状态码、字节数、CDN流转的中转节点、原站到了哪里、中转吞吐的速率、还有原站的吞吐速度都被标记出来。这样的话你就结构化的理解这条日志，可以看到这里数据的价值。当然不局限于说只有这一条，因为我们接下来还会讲到怎么去把这些数据变成有价值的东西能够展现出来。
这部分我主要想提一下，刚才说的有价值的数据我们需要做哪些转换。比如说IP需要对应到客户，这个IP到底在哪里，是广东电信还是北京联通，需要对这个数据做一个分析，不能只在字眼上面看它，不能只看到几个数字而已。接下来还有很多都需要对字符提炼出它的价值。比如说访问URL里面需要提取出来的一个是域名，因为在CDN服务商里面一个域名对应的是一个客户。而后面会有稳健的URL，这个URL里面会有一些文件的扩展名，我们也认为是可以提炼的价值点，可以知道全站里面跑的是什么内容，哪一个文件类型占的流量带宽最多。如果我要做一个成本控制的决策，就会想看一下媒体文件所占的流量和带宽是不是比较大，如果是的话我可不可以在这里入手，能节约多少带宽，如果有这个数据的话就可以很准确的做出决定，对于我们的优化就做出一个方向。 二、又拍云ELK方案 这里面我先介绍一下又拍云搜集到的日志有多少，目前来说我们全网150多个节点，有3000多台服务器，每一台服务器平均每天会产生5个GB左右的日志。这个量非常庞大，如果全部存下来的话相当于有15T，这是非常庞大的数字。我们存原始日志的服务器是大规模的存储集群，也不是持久存储，因为我们在这里还做了一些二次处理，处理过后会再放到云存储里，这才是我们真正的持久存储的地方。这里的数字非常惊人，总共有2000多亿条日志，如果只是一个很小的网站下来只有一万多条日志，你看不出来这里数据的价值，但是我有几千亿条日子的时候，所组合出来的就是非常有价值的东西。 这里是又拍云对日志做了哪一些提炼，总有做了四个部分： 第一个部分，50台高性能大存储容量的服务器组成集群，以处理原始日志格式。因为我们在日常的排错过程中会用到ID，需要快速的在这个集群里面找到当前这次访问到底出现了什么问题，只能把所有的原始日志都收集进来，所以我们就做了一个这么巨大的集群去专门做这件事情。而这个集群因为数据量太大了，刚才就说了产生的日志有15T，其实我们没办法存太长时间，所以我们只存了两天的数据。 第二个部分，4台高性能服务器组成日志下载处理集群，以提供简化的标准日志供客户下载。我们针对这些日志会做一个二次的简化处理，因为原始日志里面包含的信息太多了，提供给我们的客户下载回去有很多的数据、信息他们是不需要的。并且他们也不可能每小时都到我们这里来下载3000个节点的日志文件回去，然后再自己合并、自己排序。所以我们第二个场景是做了一个日志二次处理和简化工作的集群，而这个集群是用了4台高性能的服务器去做的，这些日志保存30天供用户下载，的延迟是1小时就可以下载到这个日志。 到了每天凌晨两点钟完成日志处理的工作之后，会马上再做一个日志统计分析，延迟可以在6小时左右，可以看到昨天我们这些日志所产生的那些统计分析。当然这个是非常简化的统计分析，它所体现出来的价值还没有我接下来要讲的价值大。 第三个部分就是我们今天讲的重点，1台普通服务器，接收所有节点的二次处理后数据，输出节点质量报告。为什么我只强调数据展现，而没有说数据分析这部分，因为我们在这里面做了大量的数据价值的提炼，还有二次的处理。其实我们把很多的中间结果扔给了ES，ES在这个场景里所起到的作用更多的是一个存储，还有一个是数据展现这样的工作。 第四个部分接收所有节点的二次处理后数据，输入到 ES，输出多纬度分析数据。但这个不是重点，所以我就没有在今天接下来打算要介绍这个部分。 刚才说到我们今天的重点是解决方案，平时我们做运维或者做研发的同事应该对日志处理这个解决方案非常熟悉。当然我们也都会经常吐槽，ELK性能不太好，并且版本3升级到4后大家都觉得性能又差了。有可能大家使用的方式有点问题，可以参考一下我们这里的使用方案。我们可以做到非常高的性能并且这个集群里面处理这么大量的数据，我们只用了一台服务器去做这件事情，并且它的资源还没跑满，只跑了10%左右，消耗CPU资源非常非常少，唯独磁盘存储的空间占用有几百G，但这几百G可是存了一个月的数据，所以我说二次提炼在这里面非常重要。 终上所述，这里我也说ELK, But Not only ELK，你要用到它但不仅仅是它，还需要做很多自己要做的事情才能把它玩转过来，它肯定不是全部。
上图是我们现在的数据处理的大的架构。这里有一个特点，CDN行业边缘节点服务器数量众多，并且他们的计算资源非常充裕，在我们的边境节点的机器CPU使用率通常都不会超过10%到20%，其实可以把很多数据处理的工作放到边缘节点。并且我们的边缘节点同时也是产生日志的地方，非常自然的就把计算的工作放到了上面去，同时在边缘做一些必要的二次处理，然后再发送到数据中心里面，数据中心专门会有一个收集的服务。这个步骤是很有必要的，不能简单的说边缘节点里面的数据能直接存入到ES集群，这不现实，因为这里面还有一些数据必须要做合并统计。比如说每一台服务器汇总回来需要合并一下，我要知道广东电信，广州那边的节点的统计数据是怎样的，这里面就会牵扯到有一个合并计算的逻辑，我们要把这个逻辑放到了中间结果收集服务里面去做的。 随后做了收集还有二次处理，合并处理之后再扔到ES集群里面。ES集群有两个功能： 第一个，当然是最主要的，把这些数据能展现出来。 第二个，它可以做一个自动告警的功能。
上图是我们刚才说的数据处理这部分的主要流程，第一个是log，log会经过我们的log分析程序。这个log分析程序里面做的主要有两个工作，一个是提炼数据的价值，另外一个是合并计算。随后它就会扔到我们后面的日志收集，再进行一次合并计算。在这里面我们出现了两次的合并计算然后再把它存入到ES集群里面。我们为什么要去做合并计算?因为一开始我就提到我们全网所产生的日志量是非常巨大的，2000多亿条数据，15T。我用50台机器的ES集群也只能存两天的数据，这样的话性能是非常低的。比如说现在我想看一下今天全网带宽统计，如果在这个集群里面看的话，我打开这个数据最少要等三四十秒，很漫长。而我们合并过了之后再存入ES，在这个场景里面我要去看我们的带宽数据，那其实基本上秒开，只要一点马上能看到昨天的带宽数据，这就是我们合并计算的价值，第一个是存的数据少了，第二是查看的性能非常高。我做了粗略的统计，我们合并可以达到的数据压缩率是1000倍以上，非常非常厉害。 三、提炼数据的价值
这个章节特意标成黑色，主要像说明这一章是非常重要的。这个章节跟其它都不一样的原因是，需要跟大家强调的是我们日志里面的价值你怎么去做二次提炼，因为你不去提炼这些日志的话，其实它是几乎没意义的东西。我们刚才一开始就说到了，通过IP是可以得到一些归属地的信息，甚至还可以通过这个IP得到一些经纬度的信息，这样的话就可以知道我的访问群体到底在全国、全世界的分布状态是怎么样的。第二个就是CDN会用到的性能必要的节点信息，还有缓存命中率，因为在刚才我们的日志里面就已经有标记了，我当前这次的请求到底是在本地缓存hits还是miss，这样就可以做缓存命中率统计。还有我们的服务状态和客户关系，因为域名对应的就是客户，今天说要去查看一下客户的带宽使用情况，下载速度怎么样，这时候是需要域名的。所以这是我们今天所讲的最重要的观点，这些日志它的价值需要我们再次提炼一下，然后存进来才有后面我们将要讲到的这些数据会产生什么样的价值。 一条简单的日志经过我们刚才的合并计算，还有数据价值的提炼，你可以得到后面的这些成果。这里是我在我们平台里截出来的数据，有很多是模糊的，没有准确的数值。 1、全网汇总信息
第一个我们可以看到全网的带宽，在左下角可以看到全网平均的下载速度，平均下载里面其实有两个状态，绿色的是缓存命中的情况下，蓝色的是miss的情况下。中间的图是我们下载速度在某一个区间的比例是多少，因为我们发现如果你纯粹去看平均速度的话，其实这个数字的价值还不够。我更希望能够知道的是，我是不是有90%的用户他的下载速度是在500k，或者说在1M左右，而不是说我有50%是在1500k，但是有50%是在几十k以下，产生了两个极端。所以说中间的下载速度区间的分布也是非常有价值的数据体现。 然后右边的图比较复杂，移鼠标上去看都有点累，主要是可以看到全国哪一个地区的带宽占比比较大一点。这个图其实最主要的价值就是可以快速实时的查看到当前整个CDN网络大概的情况。后面我们还有更多细化的数据，比如说这张图就是我们全网带宽按照带宽量从大到小排名的top50。 2、客户使用情况
这样的话你就可以看到我们现在服务的客户里面有哪些是我们的重点客户，他们跑的带宽情况怎么样。在这个图里面可以看到其实它是多维的，一个柱状里面有几个颜色，每个颜色代表的是不同的运营商。一般来说是电信的带宽占比比较大，然后是联通，移动。这里面你可以发现中间特殊黄色的那一条，这个客户非常特殊，他主要用海外节点，这个黄色对应到右边标识来看是新加坡的一个加速点，带宽使用占比90%以上。我们把这些数据合并起来放到一个图去看就可以很清楚原来平台服务的客户是这样的，没有对比的话就不知道有这样事情。如果扔给你一个G的日志不去做任何的处理、不做任何数据价值的提炼，也看不出来到底是什么，比如这个就可以让我们发现到客户的特点，可以针对这些特点去做一些商务上还有性能上的优化。 3、服务健康监控
这个图是另外一个体现，主要是讲到我们服务的质量，左上角是状态码，我们一般会是200、206健康的状态，这个图表其实是全网的。然后右上角就是我们刚才说到的下载速度，而下面右下角是两个比较特殊的是我们针对云存储的用户有一个比例标识，还有一个CDN用户原站故障或者是错误状态码出现的比例的图。这里面列的全是top10，虽然这个饼图看上去很大，但有可能你把鼠标移过去只有偶尔的几个错误，可能是在几百万个日志里面出现了几条错误，我就可以快速的判断到现在这个平台哪一个客户出现了错误，他是不是一个正常的大客户，这个客户对应的是谁，这些我们都可以快速的知道。当然这个图表还可以根据访问的域名做过滤，然后做针对性的查看服务性能。 4、业务数据分析
第三个图所展现出来主要作用是为了做CDN性能优化用的。这里面左上角最主要的是节点比例，然后在中间是覆盖地区，比如说广东电信这个ISP我们用到哪些节点。这里面可以看到左右基本上是平分，用了两个节点去覆盖这个地区。右边是这个地区的客户端所访问到的节点top10的分布。但是我们组合来看，在中间的饼图基本上能看到是50：50的两个节点为主，也就是说在右边的10个，后面的8个基本上是没亮，几乎没有请求落进去，这有可能是DNS的解析错误，或者是DNS的智能识别错误，这个具体就要看错误的比例是多少，一般来说是1%以下是无所谓的，但是要达到3%或者4%，就必须要做出一些优化的动作了。 左下角这里就是带宽的情况，在这里我可以抽取出来看到广东电信这个地区需要拿多少带宽去覆盖。这里会起到一个作用，比如说现在新疆那边要新建一个节点，但是我不知道它那边所跑的带宽需要多少，这时候怎么办?如果没有这个数据的话真的不知道怎么办，也没办法猜测那边有多少带宽。有了这个统计数据之后就可以准确的知道在新疆那边电信是1个G，联通500M，移动100M，我会给到商务这样的信息，采购资源时候就大概按照这个情况去做采购就行了，这个也是我们所提到的数据的价值。 四、难点 在这里面我们遇到了有很多难点是需要我们解决的。第一个部分，虽然说我们的机器资源很多，有几千台并行做日志处理的工作，但是这里面有一个最主要的难点是什么?不能过于消耗这些边缘的计算能力，因为在边缘节点上面最主要的工作还是要跑正常的CDN分发业务。如果说你的数据分析的程序要消耗大量的资源的话，会影响到正常的业务。所以我们对处理的性能会有非常高的要求，你只能用到10%以下的资源来去做这件事情，所以我们会用到C/gzlib，直接在原生的压缩文件日志上面做分析工作。这也是我们团队的特点，我们追求的都是非常极端的性能，而不是说能够达到目的解决这个问题就好。我们现在的日志处理程序如果说处理10G的压缩日志文件在三四十秒左右就能够把它分析完成，这是非常惊人的一个速度。 第二个点就是在接收服务器端的合并处理，使用共享内存来做数据统计，避免使用 Redis。2000亿条日志如果随便一个日志计算都要去查一下Redis，比如做一个计速器放到Redis的话就会遇到非常大的问题。如果用共享内存，或者说直接在程序内部做计速器的话，那性能可以提升一千倍、一万倍，这就是差距。所以说我们会直接自己去做这些数据结构，这个会对开发人员的要求比较高一点，比如说需要做基于C语言的开发，还要非常熟悉数据结构。数据结构在这里面主要用到的有红黑树，还有链表。这些单独来看都OK，估计大家平常也会用到，但是在做数据分析这个场景里面，其实它不是简单的说你会红黑树，或者做链表就好了，而是需要能够把这几种数据结构混合到一起去，这才是关键点。 第三个部分就是我踩的坑，这个事情上踩的坑很多。因为平台的规模不停的增长，数据也在不停的增长，没办法预计下个月日志数量级到达多少。这种情况下集群到底怎么去扩容，其实说实话没办法扩。所以第三点是要做到程序化的自动删除历史数据，一种就是粗暴一点，超过七天更旧的文件就删掉。另外一种就是针对磁盘的空余，空闲的空间有多少，比如说低于90%就开始清掉最旧的的数据，一直清到低于定的数量停掉，不然会影响到业务。 |
