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

刚才说到我们今天的重点是解决方案，平时我们做运维或者做研发的同事应该对日志处理这个解决方案非常熟悉。当然我们也都会经常吐槽，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以下，产生了两个极端。所以说中间的下载速度区间的分布也是非常有价值的数据体现。

（编辑：ASP站长网）