访问日志的大数据分析应用

本文整理自APMCon 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、全网汇总信息

（编辑：安卓应用网_ASP源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!