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

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

日志系统架构基准

有过项目开发经验的朋友都知道：从平台的最初搭建到实现核心业务，都需要有日志平台为各种业务保驾护航。

如上图所示，对于一个简单的日志应用场景，通常会准备 master/slave 两个应用。我们只需运行一个 Shell 脚本，便可查看是否存在错误信息。

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

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

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

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

正常情况下的简单流程为：应用产生日志→根据预定义的日志文件大小或时间间隔，通过执行 Logrotation，不断刷新出新的文件→定期查看→定期删除。

复杂应用场景的流程为：应用产生日志→采集→传输→按需过滤与转换→存储→分析与查看。

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

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

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

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

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

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

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

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

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

最后是追溯，我们需要在获取历史信息的同时，实现跨时间维度的对比与总结，那么追溯就能够在各种应用中发挥其关联性作用了。

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

ElasticSearch（后简称 ES），负责后端集中存储与查询工作。

单独的 Beats 负责日志的搜集。FileBeat 则改进了 Logstash 的资源占用问题；TopBeat 负责搜集监控资源，类似系统命令 top 去获取 CPU 的性能。

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

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

在此我向大家推荐一个架构学习交流群。交流学习群号：478030634  里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多 

日志系统优化思路