一个百亿级日志系统是怎么设计出来的? _日志

日志是记录系统中各种问题信息的关键，也是一种常见的海量数据。

文章插图

日志平台为集团所有业务系统提供日志采集、消费、分析、存储、索引和查询的一站式日志服务。
主要为了解决日志分散不方便查看、日志搜索操作复杂且效率低、业务异常无法及时发现等等问题。
随着有赞业务的发展与增长，每天都会产生百亿级别的日志量(据统计，平均每秒产生 50 万条日志，峰值每秒可达 80 万条) 。日志平台也随着业务的不断发展经历了多次改变和升级。
本文跟大家分享有赞在当前日志系统的建设、演进以及优化的经历，这里先抛砖引玉，欢迎大家一起交流讨论。
原有日志系统
有赞从 2016 年就开始构建适用于业务系统的统一日志平台，负责收集所有系统日志和业务日志，转化为流式数据。
通过 Flume 或者 Logstash 上传到日志中心(Kafka 集群)，然后供 Track、Storm、Spark 及其他系统实时分析处理日志。
并将日志持久化存储到 HDFS 供离线数据分析处理，或写入 ElasticSearch 提供数据查询。
整体架构如图 2-1 所示：

文章插图

图 2-1：原有日志系统架构
随着接入的应用越来越多，接入的日志量越来越大，逐渐出现一些问题和新的需求，主要在以下几个方面：

业务日志没有统一的规范，业务日志格式各式各样，新应用接入无疑大大的增加了日志的分析、检索成本。
多种数据日志数据采集方式，运维成本较高。
日志平台收集了大量用户日志信息，当时无法直接的看到某个时间段，哪些错误信息较多，增加定位问题的难度。
存储方面。

关于存储方面：

采用了 ES 默认的管理策略，所有的 Index 对应 3*2 Shard(3 个 Primary，3 个 Replica) 。

有部分 Index 数量较大，对应单个 Shard 对应的数据量就会很大，导致有 Hot Node，出现很多 bulk request rejected，同时磁盘 IO 集中在少数机器上。

对于 bulk request rejected 的日志没有处理，导致业务日志丢失。
日志默认保留 7 天，对于 SSD 作为存储介质，随着业务增长，存储成本过于高昂。
另外 Elasticsearch 集群也没有做物理隔离，ES 集群 OOM 的情况下，使得集群内全部索引都无法正常工作，不能为核心业务运行保驾护航。

现有系统演进
日志从产生到检索，主要经历以下几个阶段：

采集
传输
缓冲
处理
存储
检索

详细架构如图 3-1 所示：

文章插图

图 3-1：现有系统架构
日志接入
日志接入目前分为两种方式：

SDK 接入：日志系统提供了不同语言的 SDK，SDK 会自动将日志的内容按照统一的协议格式封装成最终的消息体，并最后最终通过 TCP 的方式发送到日志转发层(Rsyslog-Hub) 。
HTTP Web 服务接入：有些无法使用 SDK 接入日志的业务，可以通过 HTTP 请求直接发送到日志系统部署的 Web 服务，统一由 Web Protal 转发到日志缓冲层的 Kafka 集群。

日志采集

文章插图

现在有 Rsyslog-Hub 和 Web Portal 做为日志传输系统，Rsyslog 是一个快速处理收集系统日志的程序，提供了高性能、安全功能和模块化设计。
之前系统演进过程中使用过直接在宿主机上部署 Flume 的方式，由于 Flume 本身是 JAVA 开发的，会比较占用机器资源而统一升级为使用 Rsyslog 服务。
为了防止本地部署与 Kafka 客户端连接数过多，本机上的 Rsyslog 接收到数据后，不做过多的处理就直接将数据转发到 Rsyslog-Hub 集群。
通过 LVS 做负载均衡，后端的 Rsyslog-Hub 会通过解析日志的内容，提取出需要发往后端的 Kafka Topic 。
日志缓冲
Kafka 是一个高性能、高可用、易扩展的分布式日志系统，可以将整个数据处理流程解耦。
将 Kafka 集群作为日志平台的缓冲层，可以为后面的分布式日志消费服务提供异步解耦、削峰填谷的能力，也同时具备了海量数据堆积、高吞吐读写的特性。
日志切分
日志分析是重中之重，为了能够更加快速、简单、精确地处理数据。日志平台使用 Spark Streaming 流计算框架消费写入 Kafka 的业务日志。