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

架构设计

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

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

日志系统架构基准

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

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

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

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

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

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

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

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

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

实时，一般适用于我们常说的一级应用，如：直接面向用户的应用。我们可以自定义各类关键字，以方便在出现各种 ERROR 或 exception 时，相关业务人员能够在第一时间被通知到。
准实时，一般适用于一些项目管理的平台，如：在需要填写工时的时候出现了宕机，但这并不影响工资的发放。

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

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

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

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

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

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

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

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

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

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

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

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