百亿级日志系统架构设计及优化杨津萍

偏执的太偏执、 2022-01-05 11:07 278阅读 0赞

## 热烈推荐：[超多IT资源，尽在798资源网][IT_798] ##

> 声明：本文为转载文章，为防止丢失所以做此备份。  
> 作者：杨津萍,大数据架构师，从业十余年，专攻 Web 架构及大数据架构。  
> 来自：51cto技术栈(ID:blog51cto)

> **日志数据是最常见的一种海量数据，以拥有大量用户群体的电商平台为例，双 11  
> 大促活动期间，它们可能每小时的日志数量达到百亿规模，海量的日志数据暴增，随之给技术团队带来严峻的挑战。**

本文将从海量日志系统在优化、部署、监控方向如何更适应业务的需求入手，重点从多种日志系统的架构设计对比；后续调优过程：横向扩展与纵向扩展，分集群，数据分治，重写数据链路等实际现象与问题展开。

## 日志系统架构基准 ##

有过项目开发经验的朋友都知道：从平台的最初搭建到实现核心业务，都需要有日志平台为各种业务保驾护航。  
![在这里插入图片描述][20190623200831259.png]  
如上图所示，对于一个简单的日志应用场景，通常会准备 master/slave 两个应用。我们只需运行一个 Shell 脚本，便可查看是否存在错误信息。

随着业务复杂度的增加，应用场景也会变得复杂。虽然监控系统能够显示某台机器或者某个应用的错误。

然而在实际的生产环境中，由于实施了隔离，一旦在上图下侧的红框内某个应用出现了 Bug，则无法访问到其对应的日志，也就谈不上将日志取出了。

另外，有些深度依赖日志平台的应用，也可能在日志产生的时候就直接采集走，进而删除掉原始的日志文件。这些场景给我们日志系统的维护都带来了难度。  
![在这里插入图片描述][20190623200850452.png]

## 参考 Logstash，一般会有两种日志业务流程： ##

**正常情况下的简单流程为**：应用产生日志→根据预定义的日志文件大小或时间间隔，通过执行 Logrotation，不断刷新出新的文件→定期查看→定期删除。  
**复杂应用场景的流程为**：应用产生日志→采集→传输→按需过滤与转换→存储→分析与查看。  
![在这里插入图片描述][20190623200940517.png]

## 我们可以从实时性和错误分析两个维度来区分不同的日志数据场景： ##

**实时，一般适用于我们常说的一级应用**，如：直接面向用户的应用。我们可以自定义各类关键字，以方便在出现各种 error 或 exception 时，相关业务人员能够在第一时间被通知到。

**准实时，一般适用于一些项目管理的平台**，如：在需要填写工时的时候出现了宕机，但这并不影响工资的发放。

平台在几分钟后完成重启，我们可以再登录填写，该情况并不造成原则性的影响。因此，我们可以将其列为准实时的级别。

**除了直接采集错误与异常，我们还需要进行分析**。例如：仅知道某人的体重是没什么意义的，但是如果增加了性别和身高两个指标，那么我们就可以判断出此人的体重是否为标准体重。

也就是说：如果能给出多个指标，就可以对庞大的数据进行去噪，然后通过回归分析，让采集到的数据更有意义。

**此外，我们还要不断地去还原数字的真实性**。特别是对于实时的一级应用，我们要能快速地让用户明白他们所碰到现象的真实含义。

例如：商家在上架时错把商品的价格标签 100 元标成了 10 元。这会导致商品马上被抢购一空。

但是这种现象并非是业务的问题，很难被发现，因此我们只能通过日志数据进行逻辑分析，及时反馈以保证在几十秒之后将库存修改为零，从而有效地解决此问题。可见，在此应用场景中，实时分析就显得非常有用。

**最后是追溯**，我们需要在获取历史信息的同时，实现跨时间维度的对比与总结，那么追溯就能够在各种应用中发挥其关联性作用了。  
![在这里插入图片描述][20190623201032329.png]

## 上述提及的各个要素都是我们管理日志的基准。如上图所示，我们的日志系统采用的是开源的 ELK 模式： ##

*  **ElasticSearch（后简称 ES）**，负责后端集中存储与查询工作。
 *  **单独的 Beats 负责日志的搜集**。FileBeat 则改进了 Logstash 的资源占用问题；TopBeat  
    负责搜集监控资源，类似系统命令 top 去获取 CPU 的性能。

由于日志服务对于业务来说仅起到了维稳和保障的作用，而且我们需要实现快速、轻量的数据采集与传输，因此不应占用服务器太多资源。

**在方式上我们采用的是插件模式**，包括：input 插件、output 插件、以及中间负责传输过滤的插件。这些插件有着不同的规则和自己的格式，支持着各种安全性的传输。

## 日志系统优化思路 ##

![在这里插入图片描述][2019062320113772.png]

# 有了上述日志的架构，我们针对各种实际的应用场景，进一步提出了四个方面的优化思路： #

## 基础优化 ##

*  **内存**：如何分配内存、垃圾回收、增加缓存和锁。
 *  **网络**：网络传输序列化、增加压缩、策略、散列、不同协议与格式。
 *  **CPU**：用多线程提高利用率和负载。此处利用率和负载是两个不同的概念：**利用率**：在用满一个核后再用下一个内核，利用率是逐步升高的。**负载**：一下子把八个核全用上了，则负载虽然是满的，但是利用率很低。即，每核都被占用了，但是所占用的资源却不多，计算率比较低下。
 *  **磁盘**：尝试通过文件合并，减少碎片文件的产生，并减少寻道次数。同时在系统级别，通过修改设置，关闭各种无用的服务。

## 平台扩展 ##

*  **做加减法，或称替代方案**：无论是互联网应用，还是日常应用，我们在查询时都增加了分布式缓存，以有效提升查询的效率。另外，我们将不被平台使用到的地方直接关闭或去除。
 *  **纵向扩展**：如增加扩展磁盘和内存。
 *  **横向扩展**：加减/平行扩展，使用分布式集群。

## 数据分治 ##

*  **根据数据的不同维度，对数据进行分类、分级**。例如：我们从日志中区分error、info、和 debug，甚至将 info 和 debug  
    级别的日志直接过滤掉。
 *  **数据热点**：例如：某种日志数据在白天的某个时间段内呈现暴涨趋势，而晚上只是平稳产生。我们就可以根据此热点情况将它们取出来单独处理，以打散热点。

## 系统降级 ##

*  我们在对整体业务进行有效区分的基础上，通过制定一些降级方案，将部分不重要的功能停掉，以满足核心业务。

# 日志系统优化实践 #

![在这里插入图片描述][20190623201423665.png]

面对持续增长的数据量，我们虽然增加了许多资源，但是并不能从根本上解决问题。特别体现在如下三方面：

*  日志产生量庞大，每天有几百亿条。
 *  由于生产环境隔离，我们无法直接查看到数据。
 *  代理资源限制，我们的各种日志采集和系统资源采集操作，不可超过业务资源的一个核。

## 一级业务架构 ##

![在这里插入图片描述][20190623201452468.png]

我们日志系统的层次相对比较清晰，可简单分为数据接入、数据存储和数据可视化三大块。具体包括：

*  **Rsyslog**，是目前我们所接触到的采集工具中最节省性能的一种。
 *  **Kafka**，具有持久化的作用。当然它在使用到达一定数据量级时，会出现 Bug。
 *  **Fluentd**，它与 Rsyslog 类似，也是一种日志的传输工具，但是它更偏向传输服务。
 *  **ES** 和 **Kibana**。  
    ![在这里插入图片描述][20190623201536760.png]  
    该架构在实现上会用到 Golang、Ruby、Java、JS 等不同的语言。在后期改造时，我们会将符合 Key-Value 模式的数据快速地导入 HBase 之中。

基于 HBase 的自身特点，我们实现了它在内存层的 B+ 树，并且持久化到我们的磁盘之上，从而达到了理想的快速插入的速度。这也正是我们愿意选择 HBase 作为日志方案的原因。

## 二级业务架构 ##

![在这里插入图片描述][20190623201627143.png]  
我们直接来看二级业务架构的功能图，它是由如下流程串联而成的：

*  **在完成了数据采集之后，为了节省自己占用磁盘的空间**，许多应用会完全依赖于我们的日志系统。因此在数据采集完以后，我们增加了一个持久缓存。
 *  **完成缓存之后系统执行传输**。传输的过程包括：过滤和转换，这个过程可以进行数据抽稀。值得强调的是：如果业务方尽早合作并给予我们一些约定的话，我们就能够通过格式化来实现结构化的数据。
 *  **随后执行的是分流**，其主要包括两大块：一种是 A 来源的数据走 A 通道，B 来源的数据走 B 通道。另一种是让 A  
    数据流入到我们的存储设备，并触发保护机制。即为了保障存储系统，我们额外增加了一个队列。 例如：队列为 100，里面的一个 chunk 为  
    256 兆，我们现在设置高水位为 0.7、低水位为 0.3。 在写操作的堆积时，由于我们设置了 0.7，即 100 兆赫。那么在一个  
    256 兆会堆积到 70 个 chunk 时，我们往该存储平台的写速度就已经跟不上了。  
    此时高水位点会被触发，不允许继续写入，直到整个写入过程把该 chunk 消化掉，并降至 30  
    个时，方可继续往里写入。我们就是用该保护机制来保护后台以及存储设备的。
 *  **接着是存储**，由于整个数据流的量会比较大，因此在存储环节主要执行的是存储的索引、压缩、和查询。
 *  **最后是 UI 的一些分析算法**，运用 SQL的一些查询语句进行简单、快速地查询。  
    ![在这里插入图片描述][20190623202014128.png]  
    通常从采集（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 ##

![在这里插入图片描述][20190623202128332.png]  
接着是 Kafka，Kafka 主要实现的是顺序存储，它通过 topic 和消息队列的机制，实现了快速地数据存储。  
而它的缺点：由于所有的数据都向 Kafka 写入，会导致 topic 过多，引发磁盘竞争，进而严重拖累 Kafka 的性能。  
另外，如果所有的数据都使用统一标签的话，由于不知道所采集到的数据具体类别，我们将很难实现对数据的分治。  
因此，在后面的优化传输机制方面，我们改造并自己实现了顺序存储的过程，进而解决了一定要做持久化这一安全保障的需求。

## Fluentd ##

![在这里插入图片描述][20190623202201600.png]  
Fluentd 有点类似于 Logstash，它的文档和插件非常齐全。其多种插件可保证直接对接到 Hadoop 或 ES。  
就接入而言，我们可以采用 Fluentd 到 Fluentd 的方式。即在原有一层数据接入的基础上，再接一次 Fluentd。同时它也支持安全传输。当然我们在后面也对它进行了重点优化。

## ES+Kibana ##

![在这里插入图片描述][201906232022271.png]  
最后我们用到了 **ES** 和 **Kibana**。ES 的优势在于通过 Lucene 实现了快速的倒排索引。  
由于大量的日志是非结构化的，因此我们使用 ES 的 Lucene 进行包装，以满足普通用户执行非结构化日志的搜索。而 Kibana 则基于 Lucene 提供可视化显示工具。

## 问题定位与解决 ##

下面介绍一下我们碰到过的问题和现象，如下这些都是我们着手优化的出发点：

*  **传输服务器的 CPU 利用率低下，每个核的负载不饱满**。
 *  **传输服务器 Full gc 的频次过高**。由于我们是使用 Ruby 来实现的过程，其内存默认设置的数据量有时会过大。
 *  **存储服务器出现单波峰现象**，即存储服务器磁盘有时会突然出现性能直线骤升或骤降。
 *  **频繁触发高水位**。如前所述的高水位保护机制，一旦存储磁盘触发了高水位，则不再提供服务，只能等待人工进行磁盘“清洗”。
 *  **如果 ES 的一台机器“挂”了，则集群就 hang 住了**。即当发现某台机器无法通讯时，集群会认为它“挂”了，则快速启动数据恢复。而如果正值系统繁忙之时，则此类数据恢复的操作会更加拖累系统的整体性能。  
    ![在这里插入图片描述][20190623202341736.png]

由于所有数据都被写入 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 就是支持动态配置的，所以它动态配置的时候，我们在某些场景下可以提高它的写入速度，某些场景下可以支持它的这种查询效率。我们可以尝试去做一些动态配置负载。

## 改造一：存储降低 ##

![在这里插入图片描述][20190623202445175.png]  
![在这里插入图片描述][20190623202452432.png]  
降低存储在整体架构上并没有太大变化，我们只是在传输到 Fluentd 时把天数降下来，改成了一天。  
同时，我们直接进行了分流，把数据往 Hadoop 里写，而把一些符合 Kibana 的数据直接放入 ES。  
上面提过，日志查询是低频次的，一般需要查询两天以上数据的可能性很小，因此我们降低存储是非常有意义的。

## 改造二：数据分治 ##

![在这里插入图片描述][20190623202517553.png]  
我们在日志文件节点数较少（机器数量小于 5 台）的情况下，去掉了 Kafka 层。由于 Fluentd 可以支持数据和大文件存储，因此数据能够被持久化地存入磁盘。

我们给每个应用都直接对应了一个 tag，以方便各个应用对应到自己的 tag、遵循自己的固定规则、并最终写入 ES，这样就方便了出现问题的各自定位。

另外，我们运用延迟计算和文件切分也能快速地找到问题的根源。因此我们节约了 Kafka 和 ES 各种计算资源。

在实际操作中，由于 HBase 不用去做 raid，它自己完全能够控制磁盘的写入，因此我们进行了数据压缩。就其效果而言，ES 的存储开销大幅降低。

在后期，我们也尝试过一种更为极端的方案：让用户直接通过客户端的 Shell 去查询数据，并采用本地缓存的留存机制。

## 优化效果 ##

![在这里插入图片描述][20190623202543370.png]

优化的效果如下：

*  **服务器资源的有效利用**。在实施了新的方案之后，我们省了很多服务器，而且单台服务器的存储资源也节省了 15%。
 *  **单核处理每秒原来能够传输 3000 条，实施后提升到了 1.5～1.8 万条**。而且，在服务器单独空跑，即不加任何计算时，单核每秒能传输近 3 万条。
 *  **很少触发 ES 保护机制**。原因就是我们已把数据分流出来了。
 *  **以前历史数据只能存 7 天，由于我们节省了服务器，因此我们现在可以存储更长时间的数据**。而且，对于一些他人查询过的日志，我们也会根据最初的策略，有选择性地保留下来，以便追溯。

# 日志系统优化总结 #

![在这里插入图片描述][20190623203108678.png]  
![在这里插入图片描述][20190623203116533.png]  
![在这里插入图片描述][20190623203131399.png]  
关于日志平台优化，我总结了如下几点：

*  **由于日志是低频次的**，我们把历史数据存入了廉价存储之中，普通用户需要的时候，我们再导到 ES 里，通过 Kibana  
    的前端界面便可快速查询到。而对于程序员来说，则不需要到 ES 便可直接查询到。
 *  **数据存在的时间越长，则意义越小**。我们根据实际情况制定了有效的、留存有意义数据的策略。
 *  **顺序写盘替代内存**。例如：区别于平常的随机写盘，我们在操作读写一个流文件时采取的是按顺序写数据的模式。 而在存储量大的时候，则应当考虑 SSD。特别是在 ES 遇到限流时，使用 SSD 可以提升 ES 的性能。
 *  **提前定制规范，从而能够有效解决后期分析等工作**。

## 日志格式 ##

![在这里插入图片描述][20190623203149249.png]  
如上图所示，常用的日志格式类型包括：uuid、timestamp、host 等。  
特别是 host，由于日志会涉及到几百个节点，有了 host 类型，我们就能判定是哪台机器上的标准。而图中其他的环境变量类型，则能够有效地追溯到一些历史的信息。

## 日志方案 ##

![在这里插入图片描述][2019062320320114.png]  
如上图所示，我们通过 Rsyslog 可以直接将采集端的数据写入文件或数据库之中。

当然，对于一些暂时用不上的日志，我们不一定非要实施过滤传输的规则。

![在这里插入图片描述][20190623203209462.png]  
如上图，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 结合得比较紧密，它们结合在一起需要一点学习成本。

[IT_798]: https://www.798ziyuan.com
[20190623200831259.png]: /images/20211229/8a633cf3e3514fd0b0d6eee3dcfaedff.png
[20190623200850452.png]: /images/20211229/08cc20bd12b6494cb7f0e7e2730ddcfa.png
[20190623200940517.png]: /images/20211229/246c61b7e3134ecdb544e67c84f54420.png
[20190623201032329.png]: /images/20211229/de82b0aa2e944347bfc8bb4994ad3d25.png
[2019062320113772.png]: /images/20211229/75ce8c22450040fda4427eb5eadb8e98.png
[20190623201423665.png]: /images/20211229/d6e72d2ad60e4993a317a09c87cc6bab.png
[20190623201452468.png]: /images/20211229/82383dd73e3e44b6930abb9683108137.png
[20190623201536760.png]: /images/20211229/79fe4afb89fc48089880086279398b15.png
[20190623201627143.png]: /images/20211229/d37b2b07384e4653af806cd72fe34d5e.png
[20190623202014128.png]: /images/20211229/68179afd6922422d9c31bb185630816c.png
[20190623202128332.png]: /images/20211229/35b45b2bf41c4fe180feefb034b31b4f.png
[20190623202201600.png]: /images/20211229/281f4ea4490b40ebb5931db4b3a269de.png
[201906232022271.png]: /images/20211229/830e599b4dec4dc0868116e2a589b2e0.png
[20190623202341736.png]: /images/20211229/d6803b4839184e46a168992196f6f760.png
[20190623202445175.png]: /images/20211229/a337844004284e53892b15129cc1e4d8.png
[20190623202452432.png]: /images/20211229/1f158d02397d4887bd596e63eee42ba8.png
[20190623202517553.png]: /images/20211229/9c0525e45d424d9e9a13360123bebbc6.png
[20190623202543370.png]: /images/20211229/0c625c6362b1403a853c98e0880be86a.png
[20190623203108678.png]: /images/20211229/7f68320c9127401fb226dd267ecf1549.png
[20190623203116533.png]: /images/20211229/6b0f4583079f424a84be00788a4b6e6a.png
[20190623203131399.png]: /images/20211229/20937fed3b214c81b280eac5f9138ff4.png
[20190623203149249.png]: /images/20211229/9d9e6f776e5f4e19a11b4bdbd4459b3d.png
[2019062320320114.png]: /images/20211229/8ee854bab2f648b090840994a9a33ca6.png
[20190623203209462.png]: /images/20211229/8bf2deddae9b48d9878f590fc5187b4b.png