加入收藏 | 设为首页 | 会员中心 | 我要投稿 温州站长网 (https://www.0577zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

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

发布时间:2021-01-21 20:35:35 所属栏目:大数据 来源:网络整理
导读:副标题#e# 本文整理自APMCon 2016中国应用性能管理大会CDN加速专场又拍云CTO黄慧攀题为《访问日志的大数据分析应用》的演讲,现场解读了在海量访问日志中提炼多个性能指标,对日志分析系统查询需求进行分析,对访问特点进行分析,并基于性能考虑对系统架构

然后右边的图比较复杂,移鼠标上去看都有点累,主要是可以看到全国哪一个地区的带宽占比比较大一点。这个图其实最主要的价值就是可以快速实时的查看到当前整个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%就开始清掉最旧的一天的数据,一直清到低于定的数量停掉,不然会影响到业务。

(编辑:温州站长网)

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

热点阅读