【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

黄慧攀:日均 2000 亿条日志的处理智慧

  • 2016-11-15
  • 本文字数:5676 字

    阅读完需:约 19 分钟

Tech Minds 是又拍云主办的高端技术领导人私享会系列活动,先后在深圳、广州、北京成功举办,凭借私密的分享环境、高质量的对话嘉宾、前沿的行业和技术话题,又拍云 Tech Minds 已经成为技术圈子中非常受欢迎的“思想汇”活动。9 月 22 日,又拍云 Tech Minds 首次进入上海,就“做追求极致用户体验的偏执狂”的交流主题展开了激烈的讨论。

又拍云 CTO 黄慧攀在 Tech Minds No.4 上做了“访问日志的大数据分享应用”的主题分享,介绍了又拍云在访问日志方面的管理和应用方法。

又拍云目前在全球范围内部署了 4000 多台服务器,一天要产生 2000 多亿条日志,在庞大的数据量下,又拍云采取了快捷的日志管理方式,在处理日志数据时,先对日志进行预先合并计算,再存入 ELK,将记录数量压缩了 1000 倍,大大降低了海量日志数据对服务器的压力。

黄慧攀以又拍云日志系统为例,详细介绍了又拍云如何从日志信息中提炼出全网汇总数据、客户使用情况、服务健康信息等关键信息,随时感知客户的变化,快速定位问题。

以下是黄慧攀的分享全文。

大家好!我今天跟大家分享的是访问日志的大数据分析和应用。

其实在座各位都是做了好多年的技术,所以对业务里面日志的价值都会非常熟悉,所以我今天做的这个纯粹是向大家介绍一下我们又拍云是怎样做的,以及我们在这方面能够获得哪些成果,供大家参考一下,可能会从中得到有价值的东西。也请帮助我们发现做得不够好的地方。

下面两图分别是原始的日志,和格式化之后的日志,我们可以看到这一条日志里面有那些数据。在格式化的日志里面,我们注重的主要是把数据里面每一个字段的价值给提炼出来。

日志隐藏的数据价值

在我们刚才看到的那条日志里面,有客户端的访问 IP,但是如果我们只拿一个 IP 的话,其实完全看不出来它是什么东西。

又拍云会通过 IP 解析出来它的归属地和 ISP,才能知道这个用户到底是哪里的,才能准确地分析到我们影响到了哪里。比如说广东或者北京,是电信还是联通。

在请求的地址这里面,我们会提炼出来一个域名。又拍云做 CDN 业务,每一个域名要对应到不同的客户,所以这个对于我们来说价值点是非常大的,因为我要知道影响到的是哪一个客户、哪一个域名。对于单个公司来说,可能这个价值并不是特别大。但是通过这一点,可以分析出又拍云到底哪一个子业务出问题了,因为一般开发一个 App 或者网站的时候,我们也会用到多个域名。比如说 Api.huaban.com、Image.huaban.com 这样。当我们去看整体速度的时候,由于它是一个平均速度,所以看不出来到底哪一个业务受了影响,但我有了这个维度之后,我就可以看到 API 这里面是不是平均的、哪个速度出问题了,就可以准确地定位到那个影响面在哪里。

对于状态码,我们最主要是用来分析到底有没有出现什么大面积的故障,像 200、404,这种是比较正常的,那如果是 50X 的这种错误的话,就是我们的业务出现了问题,我们后端的系统就需要排查到底哪一个子系统出了问题。

服务器端吐出的字节数,对于我们网络传输这一块的价值比较大,因为我们可以通过这个去计算出一个平均的下载速度。

Content type 是资源类型,后面的那个是请求号,这也是非常重要的一个点。我的资源吞吐到客户端是多少,跟吞吐的字节数一除,就可以得到速度的数值。

日志存储,not only ELK

我们又拍云有 150 多个结点,4000 多台服务器。平均每台服务器日均产生近 5GB 压缩日志。简单计算一下,我们一天至少要产生 2000 多亿条日志,这是一个非常非常庞大的规模。

我们在处理这么多日志的时候,针对不同的统计需求、分析需求,做了四套分析的系统。

大家接触较多的是第一种类型,第一种就是我们很普通的 ELK 方案,我们用了 50 台这种高性能、大容量存储的服务器去做集群,处理原始的日志。由于刚才说到的那个日志量,量级太大了,这个集群只能存两天的数据。并且这两天的数据,查询起来的时候也比较吃力。这是用来给我们的某一个业务,比如客有一个请求,出现了 50X 的错误,那要去排查的话,需要快速定位,我可以在这一个集群里面通过 Request Id 马上找到这一条日志,它的价值点在这里。我们还会其他需求,比如说客户要下载他的全网访问日志。

所以我们做了第二个集群,在这一个集群中,我们服务器的数量明显少了很多,才 4 台,4 台高性能的服务器组成了日志下载的处理集群。这个集群可以做到一小时以内,下载前一个小时的全网日志,并且下载的日志是做了全网排序,按照时间排序。最大的延迟是 8 小时就可以看到昨天一整天的统计分析。

第三个场景是我们需要对网络做一些性能的分析。在这里,我们只用了一台普通的服务器去做,接收所有节点上面二次处理后的数据,并且可以输出到全网的节点质量报告,还可以存一个月的历史数据。历史数据是我们用来做网络调用的。这里面有一个特点,就是我们这台服务器,它压根儿没有做任何数据处理的工作,它只是做存储,还有后面的展现。

第四个,我们有一台普通的服务器。接受所有节点的二次处理的数据之后,并且输入到 ES,在这个 ES 里面,再输出多种维度的分析数据。后面的这两个将会是我们今天分享的重点,就是如何使用最少的资源达到我们需要的那个效果。

我们刚才主要在说怎么能够分析这么大量的日志,并且从这些日志里面提炼出它们的价值来。这里刚才提到了,我们会用到 ELK,但是我们普通的用法可能就只有 ELK 了,就像刚才提的那四个解决方案里面的第一种,这 50 台机器组成的一个大集群,把所有的原始日志都灌进去。但是它有明显的缺点,就是它要存的数据量实在太大,集群规模会非常庞大。我当时在北京做这个分享的时候,京东那边数据分析的朋友跟我们交流,他们是用一百多台高性能大容量的服务器组成了 ELK 的集群,来做这样一件事情。

但是我们要做的这个事情,如果仅局限于 ELK 的话,会付出非常大的成本。所以说我们“not only ELK”,还需要一些我们自己加上去的东西,才能把它管得更好。这个就是我们今天所要讲的重点。

又拍云 ELK 解决方案:1000 倍压缩效果

在又拍云 ELK 解决方案里面,ELK 它只不过是一个存储容器、展现数据,并不是我们整个解决方案里面的全部。

又拍云有一个天生的优势——在边缘有几千台服务器。每一台服务器它所产生的日志,就是一个数据源。我们可以把一些计算放到这个边缘上面去。每一台服务器我们都会有中间计算的逻辑,把日志以及日志需要提炼的点直接在本机上面做掉。这样可以加快我们数据产生的速度。

这些数据会汇聚到我们的数据中心里面,同时做一个二次的处理。有一些数据维度是针对整个节点的,所以我们在这里有一个中间层,把这些数据收集回来之后还会做一个跨节点的合并计算。这样得到一个二次计算的结果,之后才会存入到我们的 ES 里面。ES 存进去了之后,它其实就可以做出丰富的数据展现,还有做更多的,比如说监控这种事情。

接下来我说一下,我们在边缘里面进行二次处理的逻辑,我们在边缘每 5 分钟会切出一个 NGS 的访问日志文件,切出来的同时,会启动计算逻辑,这个计算逻辑在每一台机器上面都有。在这里主要是有一个合并计算,以及多维度的数据提炼。多维度的数据提炼,比如说 IP 归属地、线路、访问域名、对应客户等。这些业务逻辑都会在前面的边缘节点去完成。根据这一个 5 分钟的日志,它统计了一下之后,会合并生成一份二次处理后的数据,然后再以 JSON 的格式传到在数据中心的这个接收服务器里来,然后它再合并一下,以 JSON 的格式存到 ES 里面去。

纯裸日志数据存到集群的话,性能非常低,并且服务器的资源占用也很高,对于你的公网带宽,还有延时的挑战都很大。但是把日志进行预先的合并计算之后再存到 ELK 里面,记录的数量级别压缩了 1000 倍还不止。具体得看业务产生的原始日志量有多少。因为它不是线性增长的,它的倍率并不随着你的日志量线性增长,它只会随着你平台里面节点的数量增多而增长。在这里面,一台服务器,5 分钟跑 1000 个请求,产生的二次处理是一条。跑 10000 万个请求,出来的二次处理结果还是一条。所以说它不是一个线性的增长,日志数量越大,起到的压缩效果会更强。

日志提炼后的价值

这些数据存到 ELK 里面,读取性能很高,秒级别就可以读取到统计结果。如果使用传统的 50 台机器集群,如果要看前面一个小时的统计数据,估计得等个几十秒,甚至几分钟。
原始日志只有基础的信息,需要二次提炼才能把价值给提炼出来的。针对于又拍云的业务来说,需要提炼 IP 归属地、服务节点信息、服务状态、缓存命中率、路由状态等,其他业务或许会需要慢日志等信息。日志里能提炼很多有价值的信息,比如说 slow 是在哪一张表里、集中在哪一个字段里。这种我们都可以把它分析出来放到 ELK 里面,然后可以很直观地看到业务性能的瓶颈在哪里。

这里还有一种更简单的办法——用 APM。但是我们做技术的可能都会想,这个 APM 可能跟我们业务的吻合度不高,用 APM 这些系统去定制一些逻辑会比较困难。如果我们是自己去做原始日志的价值提炼,才能最清楚应该提炼哪些东西,也就可以很方便的做到这种操控。
用又拍云非常简单的一条 Nginx 日志举例说明一下,经过二次处理和价值提炼之后,我们得到了哪些有价值的信息。

全网汇总信息

这个是我们全网的汇总信息。在这里我们可以看到全网的总带宽情况、全网平均下载速度、全网下载速度各个区间的比例。我们把区间分成 100K 到 500K,1M,到 2M、3M、4M 这样,每一个下载区间的比例都可以很方便地看出来。右边会有一个地区的带宽占比,哪一个地区的带宽使用量是最大的,一目了然。

客户使用情况

我们可以实时地看到又拍云平台里面大客户的分布情况。具体某个客户使用的网络覆盖信息,也可以在这里面得到非常有效的展示。如果突然之间有一个大客户要加入又拍云平台,这个系统可以马上感知到,因为这个图表是每分钟刷新的。

服务健康监控

又拍云服务的健康检查,可以针对到某一个域名上面,可以看到它的全网状态,吞吐到底是 200 OK 为主,还是说出现了 50X 的错误。在这一个页面能够比较快速地查看到各类问题。

又拍云有两类客户,一种是有用到又拍云存储的,还有一种是自主源站的。

如果是用我们云存储服务的,那在左一的饼图里面,我可以看到到底哪一个节点出现的错误数据比较多,可以非常快速地定位到全网里面是不是有一个节点出现了故障。

通过右边的饼图,又拍云可以很迅速地定位到客户的哪个源站出了问题。监控部门的同事看到客户的状态异常,马上主动联系到我们的客户,告知他们的源站出了问题。

业务数据分析、合理调度资源

通过提炼日志数据,我们还可以进行业务数据分析。比如根据客户端地域、ISP 去查看 CDN 的服务情况。我们现在比较关注的是有没有做跨节点的覆盖,在这张图里就可以定位准确定位到,就是说我要看一下上海电信到底用了哪些节点去覆盖。在这个饼图里面,可以很准确地看到其实只用了两个节点,并且两个都是上海电信的节点。饼图里有非常细的紫色区域,如果这个紫色区域的比例比较大的话,就是一个异常的情况,说明我们的 DNS 解析准确度不高,或者说调度策略出问题了,把外面的那些节点弄给上海电信的用户去访问了。

这些数据信息是我们资源调度的一个依据。比如说我们现在要覆盖新疆,但是又不知道新疆的用户有多少,他们需要多少带宽。放在以前,只能盲目地提需求——我要覆盖新疆电信,你去找个节点。找个节点,是多少带宽呢?不同的带宽,采购的成本是不一样的。有了这个数据之后,我们就可以做出很准确的决定。根据全网的日志统计,新疆电信会用到 2 到 3 个 G 的带宽,并且这个是准确的数据。我可以提供准确的需求给我们采购的同事,说我要 3 个 G 的带宽,你按照这个需求确定一下采购量。

遇到的难点

以上就是我们又拍云从日志里面提炼出来的一些价值点。而我们在做这个事情的过程中,也遇到了有很多难点,或者说我们踩过的坑,这里可以分享一下。

  • 第一个是性能的问题。边缘有 4000 多台服务器,但不可能说所有的 CPU 计算资源都可以给你去做日志处理。其实每台服务器可能给到日志处理的资源的只有 1~2%。这样的话就对于二次处理的程序的性能要求就会非常高,所以我们采用了在内存中直接做流式的计算。这个对于开发难度的要求是比较高的,但它的性能很高,并且很稳定。
  • 第二个是在接收服务端的合并处理的方案上。又拍云的日志量级非常巨大,不能用一般的方案去做合并统计,比如说用 redis。redis 可能大家都认为是非常快的一个解决方案,它的性能已经非常高效了。但是在又拍云的日志场景里面,完全不能用 redis。我们主要是用共享内存去做数据统计,直接在程序里面使用内存跟使用 redis 去做计算,它们的性能差距是千倍万倍以上的——因为我们没有任何网络 IO 的产生。我用 redis 的话,起码要产生 1、2 个网络 IO,1 个网络 IO 最快都要 1、2 毫秒;但是在内存里面是纳秒,两者完全不在一个级别。
  • 第三就是程序化的自动清理历史数据,这个是我踩坑最多的地方。现在我写了一个自动化的程序去自动做历史数据的清理,在整个集群里面,数据是落到每一块磁盘上面的,每一块磁盘都会按照我的节奏,比如说今天落到 A 盘,第二天落到 B 盘。但是在清理逻辑里面,要有一个自动化的过程,就是说 A 盘的容量已经超过 90% 了,就要自动的在 A 盘里面删掉某一天的数据,把这个阈值永远控制在 90% 以内。有了自动化清理之后,就不会出现这个磁盘爆了而影响到整个集群服务的情况。一块磁盘爆了,会导致整个查看、统计出现问题,这里要强调一下,自动化的历史数据的清理的重要性。

刚才说的,在内存里做流式计算是我们整个体系里面最重要的一个环节。如果我们用开源的那些解决方案,比如说 redis,其实它的性能是非常低的,完全不用去考虑。如果它是用 java 去写的,那也不用考虑了,因为它完全没有达到这种量级的要求。

只有我们做到原生的,对日志文件不需要做解压,就能去分析、统计里面的数据,这样才能达到高的性能。这个方案对于磁盘的要求还不高,因为完全是流式处理,不会说把一个压缩日志文件解压到磁盘里面,然后再从磁盘里面读出来,然后再去统计分析。像 Hadoop 这样的方案,都是面临这个问题的,就是说这个日志文件必须是解压一下,放到集群里面,然后再做统计的分析,所以 Hadoop 的性能没办法提高到这种级别。

2016-11-15 02:461749

评论

发布
暂无评论
发现更多内容

面试官:啥是请求重放呀?

why技术

Java

话题讨论|程序员在520最想收到什么礼物?

饭饭

程序员 恋爱 520 单身

详解支撑7亿用户搜索的百度图片处理收录中台

百度Geek说

中台 搜索 图片处理

Springboot结合Netty实战聊天系统

Damon

音视频

你是否想要自由地构筑世界?51WORLD助力数字孪生开发者快速成长

Meta 小元

开发者工具 开发者关系 数字孪生 全要素场景

话题讨论|做程序员五年后是什么样子?

饭饭

程序员 职业规划 发展现状 内卷 IT行业

前端领域的数据状态统一管理机制

鲸品堂

大前端 数据 流程图 state

英特尔PK赛灵思,完美胜出!Agilex™ FPGA迎来大规模量产

E科讯

英特尔Agilex FPGA大规模量产出货,正面硬杠赛灵思

E科讯

消费者剩余:你愿意花多少钱买一件东西?

石云升

创业 产品 职场经验 5月日更

🕋【Redis干货领域】从底层彻底吃透AOF重写(原理篇)

洛神灬殇

redis持久化 aof Redis 核心技术与实战 5月日更

手撕友商7nm FPGA?英特尔“亲儿子”上阵

E科讯

Redis后端之Redis持久化

赖猫

redis 后端 LinuxC/C++

模块四作业

Chris Cheng

架构实战营

百亿级图数据在快手安全情报的应用与挑战

NebulaGraph

图数据库 大厂实践

牛!马士兵亲自教授坦克大战+精通23种设计模式,视频+笔记+源码

Java架构追梦

Java 架构 面试 23种设计模式 坦克大战

iOS 面试策略之系统框架-网络、推送与数据处理

iOSer

ios

如何自学 Java ?不报班只白嫖行不行?

Java架构师迁哥

快时代的知识形态

Ryan Zheng

Sentinel在docker中获取CPU利用率的一个BUG

捉虫大师

Java Docker sentinel

音视频开发视频和视频帧:ffmpeg的RTMP推流

赖猫

音视频 ffmpeg 推流 RTMP RTSP

如何模拟弱网环境?

运维研习社

Linux 运维 网络 5月日更

SpringCloudRPC远程调用核心原理:代理模式与RPC客户端实现类

小Q

Java 学习 架构 面试

领域驱动设计(DDD)

码语者

DDD

上架Google Play应用如何适配Android 11?

YonBuilder低代码开发平台

面试让HR都能听懂的MySQL锁机制详解

linux大本营

MySQL 数据库 Linux 后台开发

鸿蒙轻内核M核源码分析:数据结构之任务就绪队列

华为云开发者联盟

鸿蒙 数据结构 数组 双向循环链表 任务就绪队列

云时代的数据之约

BinTools图尔兹

数据库 云计算 运维 云服务 dba

数字化转型助推,200亿元数据治理市场空间充满想象

DT极客

Rust从0到1-集合-Hash Map

rust hashmap 集合 Collections hash map

Nextcloud一站式体验

白粥

NAS Nextcloud

黄慧攀:日均2000亿条日志的处理智慧_语言 & 开发_黄慧攀_InfoQ精选文章