本文来自于51CTO技术栈,日志数据是最常见的一种海量数据,以拥有大量用户群体的电商平台为例,双 11 大促活动期间,它们可能每小时的日志数量达到百亿规模,海量的日志数据暴增,随之给技术团队带来严峻的挑战。
![9ee240eb833bc9091928f5211578f174.png](https://i-blog.csdnimg.cn/blog_migrate/efe98a89f205ac3d7d5e077f33a923ce.jpeg)
本文将从海量日志系统在优化、部署、监控方向如何更适应业务的需求入手,重点从多种日志系统的架构设计对比;后续调优过程:横向扩展与纵向扩展,分集群,数据分治,重写数据链路等实际现象与问题展开。
日志系统架构基准
有过项目开发经验的朋友都知道:从平台的最初搭建到实现核心业务,都需要有日志平台为各种业务保驾护航。
![71b115b87f4b0ec6106bb6c5c4776061.png](https://i-blog.csdnimg.cn/blog_migrate/dc001bd875a98e16c8204bcdac5500df.jpeg)
如上图所示,对于一个简单的日志应用场景,通常会准备 master/slave 两个应用。我们只需运行一个 Shell 脚本,便可查看是否存在错误信息。
随着业务复杂度的增加,应用场景也会变得复杂。虽然监控系统能够显示某台机器或者某个应用的错误。
然而在实际的生产环境中,由于实施了隔离,一旦在上图下侧的红框内某个应用出现了 Bug,则无法访问到其对应的日志,也就谈不上将日志取出了。
另外,有些深度依赖日志平台的应用,也可能在日志产生的时候就直接采集走,进而删除掉原始的日志文件。这些场景给我们日志系统的维护都带来了难度。
![ef2efa0074af2af516ed1c5d3e6863ba.png](https://i-blog.csdnimg.cn/blog_migrate/e2a5f1d0b41625d17fc3252fd1a1fe99.jpeg)
参考 Logstash,一般会有两种日志业务流程:
正常情况下的简单流程为:应用产生日志→根据预定义的日志文件大小或时间间隔,通过执行 Logrotation,不断刷新出新的文件→定期查看→定期删除。
复杂应用场景的流程为:应用产生日志→采集→传输→按需过滤与转换→存储→分析与查看。
![82d11957170d72e51f7177d98e68afa2.png](https://i-blog.csdnimg.cn/blog_migrate/f1cbe89e6f97345039bb77d42d573935.jpeg)
我们可以从实时性和错误分析两个维度来区分不同的日志数据场景:
实时,一般适用于我们常说的一级应用,如:直接面向用户的应用。我们可以自定义各类关键字,以方便在出现各种 error 或 exception 时,相关业务人员能够在第一时间被通知到。
准实时,一般适用于一些项目管理的平台,如:在需要填写工时的时候出现了宕机,但这并不影响工资的发放。
平台在几分钟后完成重启,我们可以再登录填写,该情况并不造成原则性的影响。因此,我们可以将其列为准实时的级别。
除了直接采集错误与异常,我们还需要进行分析。例如:仅知道某人的体重是没什么意义的,但是如果增加了性别和身高两个指标,那么我们就可以判断出此人的体重是否为标准体重。
也就是说:如果能给出多个指标,就可以对庞大的数据进行去噪,然后通过回归分析,让采集到的数据更有意义。
此外,我们还要不断地去还原数字的真实性。特别是对于实时的一级应用,我们要能快速地让用户明白他们所碰到现象的真实含义。
例如:商家在上架时错把商品的价格标签 100 元标成了 10 元。这会导致商品马上被抢购一空。
但是这种现象并非是业务的问题,很难被发现,因此我们只能通过日志数据进行逻辑分析,及时反馈以保证在几十秒之后将库存修改为零,从而有效地解决此问题。可见,在此应用场景中,实时分析就显得非常有用。
最后是追溯,我们需要在获取历史信息的同时,实现跨时间维度的对比与总结,那么追溯就能够在各种应用中发挥其关联性作用了。
![6356267e3a14080b87ee8db4b5911380.png](https://i-blog.csdnimg.cn/blog_migrate/e863655fce006fb9af460baade54cae7.jpeg)
上述提及的各个要素都是我们管理日志的基准。如上图所示,我们的日志系统采用的是开源的 ELK 模式:
ElasticSearch(后简称 ES),负责后端集中存储与查询工作。
单独的 Beats 负责日志的搜集。FileBeat 则改进了 Logstash 的资源占用问题;TopBeat 负责搜集监控资源,类似系统命令 top 去获取 CPU 的性能。
由于日志服务对于业务来说仅起到了维稳和保障的作用,而且我们需要实现快速、轻量的数据采集与传输,因此不应占用服务器太多资源。
在方式上我们采用的是插件模式,包括:input 插件、output 插件、以及中间负责传输过滤的插件。这些插件有着不同的规则和自己的格式,支持着各种安全性的传输。
日志系统优化思路
![2d42223fe776f57007b0e5f14d8456cd.png](https://i-blog.csdnimg.cn/blog_migrate/5437e96fdff608ecba63de618c7035c9.jpeg)
有了上述日志的架构,我们针对各种实际的应用场景,进一步提出了四个方面的优化思路:
基础优化
内存:如何分配内存、垃圾回收、增加缓存和锁。
网络:网络传输序列化、增加压缩、策略、散列、不同协议与格式。
CPU:用多线程提高利用率和负载。
此处利用率和负载是两个不同的概念:
利用率:在用满一个核后再用下一个内核,利用率是逐步升高的。
负载:一下子把八个核全用上了,则负载虽然是满的,但是利用率很低。即,每核都被占用了,但是所占用的资源却不多,计算率比较低下。
磁盘:尝试通过文件合并,减少碎片文件的产生,并减少寻道次数。同时在系统级别,通过修改设置,关闭各种无用的服务。
平台扩展
做加减法,或称替代方案:无论是互联网应用,还是日常应用,我们在查询时都增加了分布式缓存,以有效提升查询的效率。另外,我们将不被平台使用到的地方直接关闭或去除。
纵向扩展:如增加扩展磁盘和内存。
横向扩展:加减/平行扩展,使用分布式集群。
数据分治
根据数据的不同维度,对数据进行分类、分级。例如:我们从日志中区分error、info、和 debug,甚至将 info 和 debug 级别的日志直接过滤掉。
数据热点:例如:某种日志数据在白天的某个时间段内呈现暴涨趋势,而晚上只是平稳产生。我们就可以根据此热点情况将它们取出来单独处理,以打散热点。
系统降级
我们在对整体业务进行有效区分的基础上,通过制定一些降级方案,将部分不重要的功能停掉,以满足核心业务。
日志系统优化实践
![befabdd509e3ad3a5ab1bb18608d2d0e.png](https://i-blog.csdnimg.cn/blog_migrate/bb3d27335d860805e7afa35eb5e5106b.jpeg)
面对持续增长的数据量,我们虽然增加了许多资源,但是并不能从根本上解决问题。
特别体现在如下三方面:
日志产生量庞大,每天有几百亿条。
由于生产环境隔离,我们无法直接查看到数据。
代理资源限制,我们的各种日志采集和系统资源采集操作,不可超过业务资源的一个核。
一级业务架构
![65fe0c08c29a366697dfd16c2c235e27.png](https://i-blog.csdnimg.cn/blog_migrate/1eb74ff8e2483316a572804e0a8e352e.jpeg)
我们日志系统的层次相对比较清晰,可简单分为数据接入、数据存储和数据可视化三大块。
具体包括:
Rsyslog,是目前我们所接触到的采集工具中最节省性能的一种。
Kafka,具有持久化的作用。当然它在使用到达一定数据量级时,会出现 Bug。
Fluentd,它与 Rsyslog 类似,也是一种日志的传输工具,但是它更偏向传输服务。
ES 和 Kibana。
![096518cb6232a5c7ba31e42dd46d8909.png](https://i-blog.csdnimg.cn/blog_migrate/87a7480694833995f0c21bb53297dc08.jpeg)
该架构在实现上会用到 Golang、Ruby、Java、JS 等不同的语言。在后期改造时,我们会将符合 Key-Value 模式的数据快速地导入 HBase 之中。
基于 HBase 的自身特点,我们实现了它在内存层的 B+ 树,并且持久化到我们的磁盘之上,从而达到了理想的快速插入的速度。这也正是我们愿意选择 HBase 作为日志方案的原因。
二级业务架构
![781976d35eb84e8e3598346fdc8118e4.png](https://i-blog.csdnimg.cn/blog_migrate/33959668bae96a3b555d384a2f3db644.jpeg)
我们直接来看二级业务架构的功能图,它是由如下流程串联而成的:
在完成了数据采集之后,为了节省自己占用磁盘的空间,许多应用会完全依赖于我们的日志系统。因此在数据采集完以后,我们增加了一个持久缓存。
完成缓存之后系统执行传输。传输的过程包括:过滤和转换,这个过程可以进行数据抽稀。值得强调的是:如果业务方尽早合作并给予我们一些约定的话,我们就能够通过格式化来实现结构化的数据。
随后执行的是分流,其主要包括两大块:一种是 A 来源的数据走 A 通道,B 来源的数据走 B 通道。另一种是让 A 数据流入到我们的存储设备,并触发保护机制。即为了保障存储系统,我们额外增加了一个队列。
例如:队列为 100,里面的一个 chunk 为 256 兆,我们现在设置高水位为 0.7、低水位为 0.3。
在写操作的堆积时,由于我们设置了 0.7,即 100 兆赫。那么在一个 256 兆会堆积到 70 个 chunk 时,我们往该存储平台的写速度就已经跟不上了。
此时高水位点会被触发,不允许继续写入,直到整个写入过程把该 chunk 消化掉,并降至 30 个时,方可继续往里写入。我们就是用该保护机制来保护后台以及存储设备的。
接着是存储,由于整个数据流的量会比较大,因此在存储环节主要执行的是存储的索引、压缩、和查询。
最后是 UI 的一些分析算法,运用 SQL 的一些查询语句进行简单、快速地查询。
![06f55ab4808bce10c0f5141550d7cc7b.png](https://i-blog.csdnimg.cn/blog_migrate/56d6bb496ec071858f9b32e895b3e3c1.jpeg)
通常从采集(logstash/rsyslog/heka/filebeat)到面向缓存的 Kafka 是一种典型的宽依赖。
所谓宽依赖,是指每个 App 都可能跟每个 Broker 相关联。在 Kafka 处,每次传输都要在哈希之后,再把数据写到每个 Broker 上。
而窄依赖,则是其每一个 Fluentd 进程都只对应一个 Broker 的过程。最终通过宽依赖过程写入到 ES。
采集
如 Rsyslog 不但占用资源最少,而且可以添加各种规则,它还能支持像 TSL、SSL 之类的安全协议。
Filebeat 轻量,在版本 5.x 中,Elasticsearch 具有解析的能力(像 Logstash 过滤器)— Ingest。
这也就意味着可以将数据直接用 Filebeat 推送到 Elasticsearch,并让 Elasticsearch 既做解析的事情,又做存储的事情。
Kafka
![236e1ddc4fdd74d7323d308c94444a8a.png](https://i-blog.csdnimg.cn/blog_migrate/aa80a3cd6b4c83557ae311d51c4afbda.jpeg)
接着是 Kafka,Kafka 主要实现的是顺序存储,它通过 topic 和消息队列的机制,实现了快速地数据存储。
而它的缺点:由于所有的数据都向 Kafka 写入,会导致 topic 过多,引发磁盘竞争,进而严重拖累 Kafka 的性能。
另外,如果所有的数据都使用统一标签的话,由于不知道所采集到的数据具体类别,我们将很难实现对数据的分治。
因此,在后面的优化传输机制方面,我们改造并自己实现了顺序存储的过程,进而解决了一定要做持久化这一安全保障的需求。
Fluentd
![fb77cdf4e625f164718a411825384837.png](https://i-blog.csdnimg.cn/blog_migrate/f2821a3b7b75c537e44ac459271c45dc.jpeg)
Fluentd 有点类似于 Logstash,它的文档和插件非常齐全。其多种插件可保证直接对接到 Hadoop 或 ES。
就接入而言,我们可以采用 Fluentd 到 Fluentd 的方式。即在原有一层数据接入的基础上,再接一次 Fluentd。同时它也支持安全传输。当然我们在后面也对它进行了重点优化。
ES+Kibana
![74f93a131d92f396ff38bff0f0965048.png](https://i-blog.csdnimg.cn/blog_migrate/f4d06152e9b333630c8dc4b80cd551f2.jpeg)
最后我们用到了 ES 和 Kibana。ES 的优势在于通过 Lucene 实现了快速的倒排索引。
由于大量的日志是非结构化的,因此我们使用 ES 的 Lucene 进行包装,以满足普通用户执行非结构化日志的搜索。而 Kibana 则基于 Lucene 提供可视化显示工具。
问题定位与解决
下面介绍一下我们碰到过的问题和现象,如下这些都是我们着手优化的出发点:
传输服务器的 CPU 利用率低下,每个核的负载不饱满。
传输服务器 Full gc 的频次过高。由于我们是使用 Ruby 来实现的过程,其内存默认设置的数据量有时会过大。
存储服务器出现单波峰现象,即存储服务器磁盘有时会突然出现性能直线骤升或骤降。
频繁触发高水位。如前所述的高水位保护机制,一旦存储磁盘触发了高水位,则不再提供服务,只能等待人工进行磁盘“清洗”。
如果 ES 的一台机器“挂”了,则集群就 hang 住了。即当发现某台机器无法通讯时,集群会认为它“挂”了,则快速启动数据恢复。而如果正值系统繁忙之时,则此类数据恢复的操作会更加拖累系统的整体性能。
![c67f15f6383d66c70c1252499bbf3684.png](https://i-blog.csdnimg.cn/blog_migrate/7bf1a95d83c30c2397931aa01fc78ec5.jpeg)
由于所有数据都被写入 Kafka,而我们只用到了一个 topic,这就造成了每一类数据都要经过不一定与之相关的规则链,并进行不一定适用的规则判断,因此数据的传输效率整体被降低了。
Fluentd 的 host 轮询机制造成高水位频发。由于 Fluentd 在与 ES 对接时遵循一个默认策略:首选前五台进行数据写入,即与前五台的前五个接口交互。
在我们的生产环境中,Fluentd 是用 CRuby 写的。每一个进程属于一个 Fluentd 进程,且每一个进程都会对应一个 host 文件。
而该 host 文件的前五个默认值即为 ES 的写入入口,因此所有机器都会去找这五个入口。
倘若有一台机器宕机,则会轮询到下一台。如此直接造成了高水位的频繁出现、和写入速度的下降。
众所周知,对日志的查询是一种低频次的查询,即只有在出现问题时才会去查看。但是在实际操作中,我们往往通过检索的方式全部取出,因此意义不大。
另外 ES 为了达到较好的性能,会将数据存储在 raid0 中,存储的时间跨度往往会超过 7 天,因此其成本也比较高。
通过对数据的实时线分析,我们发现并未达到写入/写出的平衡状态。
为了提高 Fluentd 的利用率,我们用 Kafka 去数据的时候提高了量,原来是 5 兆,现在我们改到了 6 兆。
如果只是单纯传输,不论计算的话,其实可以改更高。只不过因为我们考虑到这里包含了计算的一些东西,所以只提到了 6 兆。
我们的 Fluentd 是基于 JRuby 的,因为 JRuby 可以多线程,但是我们的 CRuby 没有任何意义。
为了提高内存,我把 Ruby 所有的内存机制了解了一下,就是散列的一些 host 文件,因为我们每个进程都选前五列就可以了,我多开了几个口。ES 的优化这一块,在上 ES 之前,我们已经有人做过一次优化了。
因为基于我刚才说的有时候日志量很高,有时候日志量很少。我们会考虑做动态配置。
因为 ES 就是支持动态配置的,所以它动态配置的时候,我们在某些场景下可以提高它的写入速度,某些场景下可以支持它的这种查询效率。我们可以尝试去做一些动态配置负载。
改造一:存储降低
![72e33afbbd9ae6e4aef866502bcd14c1.png](https://i-blog.csdnimg.cn/blog_migrate/d95f88e645febfba61d2d3ff1ca22893.jpeg)
![093fe5ed7e39af531d61f0fefb3246d0.png](https://i-blog.csdnimg.cn/blog_migrate/6fa14549ce694eae13d52d963946dfed.jpeg)
降低存储在整体架构上并没有太大变化,我们只是在传输到 Fluentd 时把天数降下来,改成了一天。
同时,我们直接进行了分流,把数据往 Hadoop 里写,而把一些符合 Kibana 的数据直接放入 ES。
上面提过,日志查询是低频次的,一般需要查询两天以上数据的可能性很小,因此我们降低存储是非常有意义的。
改造二:数据分治
![aa50208500b3fcaf26f74d99838c608d.png](https://i-blog.csdnimg.cn/blog_migrate/274cd09eff94c53c9f2dd844f4e74750.jpeg)
我们在日志文件节点数较少(机器数量小于 5 台)的情况下,去掉了 Kafka 层。由于 Fluentd 可以支持数据和大文件存储,因此数据能够被持久化地存入磁盘。
我们给每个应用都直接对应了一个 tag,以方便各个应用对应到自己的 tag、遵循自己的固定规则、并最终写入 ES,这样就方便了出现问题的各自定位。
另外,我们运用延迟计算和文件切分也能快速地找到问题的根源。因此我们节约了 Kafka 和 ES 各种计算资源。
在实际操作中,由于 HBase 不用去做 raid,它自己完全能够控制磁盘的写入,因此我们进行了数据压缩。就其效果而言,ES 的存储开销大幅降低。
在后期,我们也尝试过一种更为极端的方案:让用户直接通过客户端的 Shell 去查询数据,并采用本地缓存的留存机制。
优化效果
![a881b19cca67d37fb0d089e846c4c319.png](https://i-blog.csdnimg.cn/blog_migrate/e93e7d81e5644ae91bc9bc1ca647ae29.jpeg)
优化的效果如下:
服务器资源的有效利用。在实施了新的方案之后,我们省了很多服务器,而且单台服务器的存储资源也节省了 15%。
单核处理每秒原来能够传输 3000 条,实施后提升到了 1.5~1.8 万条。而且,在服务器单独空跑,即不加任何计算时,单核每秒能传输近 3 万条。
很少触发 ES 保护机制。原因就是我们已把数据分流出来了。
以前历史数据只能存 7 天,由于我们节省了服务器,因此我们现在可以存储更长时间的数据。而且,对于一些他人查询过的日志,我们也会根据最初的策略,有选择性地保留下来,以便追溯。
日志系统优化总结
![ee44a640824c71e13cc32254f14f4957.png](https://i-blog.csdnimg.cn/blog_migrate/31240ea1d389baa780597962d01ff773.jpeg)
![be3c46aee7716e9c5715f8f60a68338e.png](https://i-blog.csdnimg.cn/blog_migrate/d1e59248b292645746e181417fdeaecf.jpeg)
![4197b965b56f531c792b276d75a7aaba.png](https://i-blog.csdnimg.cn/blog_migrate/8c8c84d93685f8424f18b4d85eccd6a6.jpeg)
关于日志平台优化,我总结了如下几点:
由于日志是低频次的,我们把历史数据存入了廉价存储之中,普通用户需要的时候,我们再导到 ES 里,通过 Kibana 的前端界面便可快速查询到。而对于程序员来说,则不需要到 ES 便可直接查询到。
数据存在的时间越长,则意义越小。我们根据实际情况制定了有效的、留存有意义数据的策略。
顺序写盘替代内存。例如:区别于平常的随机写盘,我们在操作读写一个流文件时采取的是按顺序写数据的模式。
而在存储量大的时候,则应当考虑 SSD。特别是在 ES 遇到限流时,使用 SSD 可以提升 ES 的性能。
提前定制规范,从而能够有效解决后期分析等工作。
日志格式
![451a4be098aa5f3f7c1f0dca82ed1e4b.png](https://i-blog.csdnimg.cn/blog_migrate/f334192326bd50e4e2dd1de160836473.jpeg)
如上图所示,常用的日志格式类型包括:uuid、timestamp、host 等。
特别是 host,由于日志会涉及到几百个节点,有了 host 类型,我们就能判定是哪台机器上的标准。而图中其他的环境变量类型,则能够有效地追溯到一些历史的信息。
日志方案
![31a7a2162a242963acc9133c600192da.png](https://i-blog.csdnimg.cn/blog_migrate/0f5ab8a6471ed1728bdbf52563dccc6e.jpeg)
如上图所示,我们通过 Rsyslog 可以直接将采集端的数据写入文件或数据库之中。
当然,对于一些暂时用不上的日志,我们不一定非要实施过滤传输的规则。
![8480ca6a5f177eb29af3c74ddf5ef9d2.png](https://i-blog.csdnimg.cn/blog_migrate/1d861fec09b31f74833d190974a4641b.jpeg)
如上图,Fluentd 也有一些传输的规则,包括:Fluentd 可以直接对接 Fluentd,也可以直接对接 MongoDB、MySQL 等。
另外,我们也有一些组件可以快速地对接插件和系统,例如让 Fluentd 和 Rsyslog 能够直接连到 ES 上。
这是我个人给大家定制的一些最基本的基线,我认为日志从采集、缓存、传输、存储,到最终可视化,分成了三套基线。
采集到存储是最简单的一个,像 Rsyslog 到 hdfs 或者其他 filesystem,我们有这种情况。
比较常见的情况,就是从采集、传输、到存储可视化,然后形成最终我们现在最复杂的一套系统,大家可以根据实际情况取舍。
最后是我考虑到一个实际情况,假如这个案例,我们尽可能少的占有服务器,然后传输需要过滤转换,日志可以比较简单,符合这种 Key value(KV)格式。
我们可以按照取了一个 Rsyslog、取了一个 Fluentd、取了一个 Hbase,取了一个 echars 等这么一个方式做一个方案就可以了。
我觉得 Rsyslog、Fluentd、heka 这些都可以做采集。然后传输这块有 Fluentd 传输,因为 Fluentd 和 Kafka 到插件非常灵活可以直接对接我们很多存储设备,也可以对应很多的文件、连 ES 都可以。
可视化可以用 Kibana,主要是跟 ES 结合得比较紧密,它们结合在一起需要一点学习成本。