《中国民生银行天眼日志平台架构演进的平凡之路》阅读有感

随着中国民生银行的 IT 业务系统的迅速发展，主机、设备、系统、应用软件数量不断增多，业务资源访问、操作量不断增加，对于应用整体系统智能分析与处理的要求不断提高, 急需建立包含所有应用、系统、存储、设备的统一的日志集中管理平台。本文分享了中国民生银行大数据基础产品团队如何基于 ELK 技术栈构建自己的天眼日志平台以及平台架构优化、升级和演进的过程。
基于 ELK（Elasticsearch＋Logstash＋Kibana）建立一体化日志平台，提供日志收集、处理、存储、搜索、展示等全方位功能。通过日志的收集、传输、储存，对海量系统日志进行集中管理和准实时搜索分析，帮助运维人员进行业务准实时监控、故障定位及排除、业务趋势分析、安全与合规审计等工作，深度挖掘日志的大数据价值。

目前接入天眼日志平台的日志覆盖了应用、操作系统、数据库、中间件、存储和管理口日志数据，同时对于各个模块部分指标进行采集和存储。

早期的平台架构

早期的天眼日志平台使用了原始的 ELK 三层架构模式：多个独立的 Logstash agent(shipper) 负责收集不同来源的数据，一个中心 agent(Indexer) 负责汇总和分析数据，在中心 agent 前的 Broker 使用 Redis 作为缓冲区，中心 agent 后的 Elasticsearch（后简称 ES）用于存储和搜索数据，应用可以采用定制化的 Kibana 提供丰富的图表展示，也可以根据 ES 的 RESTful API 行开发定制。

• 采集层：shipper 表示日志收集，使用 Logstash 收集各种来源的数据，启动时随机在 Redis 服务器列表中选择一个服务器进行对 Broker 的连接。
• 缓冲层：Broker 作为远程 shipper 与中心 Indexer 之间的缓冲区，使用 Redis 实现，一是可以提高系统的性能，二是可以提高系统的可靠性，当中心 Indexer 提取数据失败时，数据保存在 Redis 中而不至于丢失。
• 处理层： 中心 Indexer 也采用 Logstash，从 Broker 中提取数据，可以执行相关的分析和处理 (filter)；一个 Indexer 会轮询从多个 Redis 进行数据获取，这样防止了一个 Indexer 宕后对应的 Broker 无人处理。
• 存储层：Elasticsearch 用于存储最终的数据，并提供搜索功能。
• 展示层：Kibana 提供一个简单、丰富的 web 界面，数据来自于 Elasticsearch，支持各种查询、统计和展示。

经过一年多的时间，随着日志平台的发展，接入日志量呈几何级增长，日志写入请求给服务器带来很大的性能压力，同时应用运维人员对平台的需求越来越复杂和多样性，前期架构设计带来的各个层次的一系列问题都逐步暴露出来：

1. 采集层基于 Logstash 实现的 agent 平台类别受限，无法支持 AIX、HP_UNIX 等 Unix 操作系统，同时通用的开源产品 Flume 功能比较单一，无法满足我们常规的日志收集需求。
2. agent 日志解析对资源消耗较多，迫切需要将日志的分析与处理提升到后端处理层。
3. 缓冲层无法提供分布式消息队列服务，同时容量和效率亟待提高。
4. 存储层原始版本组件功能有缺陷，版本迭代较快，需要集中升级。
5. 展示层缺乏场景统一管理入口，各个应用场景相互独立不具备通用性。基于上述问题，我们设计了新的架构。

天眼日志平台目前已经接入 58 个应用系统，其中 A、B 类重要核心应用 44 个，覆盖了 500+ 的服务器，日均 5T 的数据写入量，可以很好地支持运维应用人员对日志文件进行智能分析与处理，达到了平台日志收集、处理、存储、搜索、展示等全方位功能要求。下面我们分别对这个架构中我们所做的一些工作和大家进行分享。

采集层（Agent） 适配 Unix 操作系统

在 Agent 层，为了更好地适配更多样的操作系统，我们主要采用 Logstash 和 Flume 进行日志和指标采集，在这个过程中对 Flume 进行了较多的定制，并进行了社区回馈。

首先，我们在 Linux 操作系统上采用 Logstash 进行日志的采集和初步解析。但是由于 Logstash 的 jvm 环境不是标准的 jdk，在 HP_UNIX 和 AIX 操作系统 Logstash 无法运行，所以这两类操作系统使用 Flume 进行日志采集。所有 agent 的解析文件都是通用的，Logstash 一类通用，Flume 一类通用。如果通用日志的系统上（主要是中间件）同时需要采集应用日志，Logstash 需要配置将应用日志和系统日志的采集逻辑都包含进去，原则就是一台机器采集日志的 Logstash/Flume agent 只启动一个进程。而对于操作系统的 syslog 和存储设备日志的采集方式是集中采集，使用单独的 Logstash agent 进行解析上送。

Flume 我们最初使用的版本是 Apache Flume 1.6，在使用 Taildir Source 组件和核心组件的过程中，发现其无法完全满足我们的需求，例如：

1. 若 filegroup 路径中包含正则表达式，则无法获取文件的完整路径，在日志入到 Elasticsearch 后无法定位日志的路径；
2. Taildir Source 不支持将多行合并为一个 event，只能一行一行读取文件；
3. filegroup 配置中不支持目录包含正则表达式，不便配置包含多个日期并且日期自动增长的目录，例如 /app/logs/yyyymmdd/appLog.log；
4. 在使用 Host Interceptor 时，发现只能保留主机名或者是 IP，二者无法同时保留。

在研究 Flume 源码之后，我们在源码上扩展开发。截至目前，我们为开源社区贡献了如下 4 个 Patch，其中 FLUME-2955 已被社区 Merge 并在 1.7 版本中发布。有关 4 个 Patch 的详细细节介绍请参见《拥抱开源，回馈社区：民生银行 Flume 源码贡献实践》。

另外我们在 Github 上开放了一个版本，将 FLUME-2960/2961/3187 三个 Patch 合并到 Flume 1.7 上，欢迎大家试用，地址：

https://github.com/tinawenqiao/flume，分支名 trunk-cmbc。

Flume 配置样例如下：

源端采集 Agent 轻量化

随着日志接入工作的不断推进，日志解析都是在 agent 端进行的弊病显露出来。由于 Logstash 是使用 Java 编写，插件是使用 jruby 编写，又需要 jvm 环境运行，对服务器的资源要求会比较高。同时 Logstash 在使用 filter/grok 插件处理复杂的日志字段抽取和预处理时，正则解析会耗费大量的 cpu 资源，在初始启动的一瞬间偶尔会冲破 cpu 监控报警阀值，有可能影响生产服务器。虽然目前还没发现对应用产生实际负面影响（agent 有监控脚本自杀机制），但是导致应用运维人员会非常紧张，在后来的架构演进中，我们正逐步取消源端解析而改为后台解析。

随着 Elastic 技术堆栈的发展，出现了 Filebeat。Filebeat 是 Beat 成员之一，基于 Go 语言编写，无任何依赖，比 Logstash 更加轻量，非常适合安装在生产机器上，不会带来过高的资源占用。对比测试中我们创建了 1 个 G 的日志数据，不做正则解析，在分配同样资源的情况下，单线程 logtash 启动 cpu 瞬间飚高到 80%，后面基本上在 60% 左右，63s 处理完毕，Filebeat 启动时 cpu 瞬间在 40% 左右，之后在 20% 左右，15s 处理完毕。从结果上来看不管是性能还是资源占比 Filebeat 都比 Logstash 要好上不少。在后期演进中，我们逐步在新架构中将日志解析的工作放在了后端进行，只需要 Filebeat 将收集的日志整合原样上送即可。

Agent 统一管控和性能监控

由于上一代原始架构平台部署的 agent 缺乏统一管理功能，相关配置信息均需要手工实施，自动化程度较弱，也无法与其他系统关联。对此我们在新的日志平台架构下依赖大数据管控平台完成相关自动化需求，大数据管控平台是我们大数据基础产品团队自主开发的一套对大数据集群和天眼日志平台中 agent 统一运维管控的项目，具备智能服务发现和服务器管理功能。大数据管控平台上线实现了日志平台 agent 的自动化部署、点击触发启停和监控可视化，监控可视化通过 Filebeat 和 Flume 上送心跳信息到 Kafka 上，在 Storm 集群上开发拓扑程序消费 Kafka 心跳信息存入到大数据管控平台的 MySQL 数据库中进行展示。另外通过大数据管控平台与工单系统、服务目录、CMDB 系统进行联动，日志平台本身只充当基础框架，统一认证权限添加、元数据信息下发、工单数据流处理都通过管控平台页面 agent 配置文件的集群模块化录入和上传来实现。

在 Agent 资源消耗方面，除了进行必要的优化手段外，我们还在部署 agent 的同时配套配置 agent 进程监控，由集中监控平台进行统一部署，同时在 agent 端部署一个 crontab 脚本，发现监控报警后即刻将占用较高资源（cpu、内存、存储）的 agent 进程杀掉，避免采集 agent 对应用系统性能造成影响。

明确日志规范

在应用日志规范上，我们规定应用日志中要求必须带时间戳，这个时间戳在 agent 进行采集时会作为默认的 @timestamp。Logstash agent 需要增加应用英文简称，Flume agent 需要使用 avro 序列化方式在 head 头里增加 appname、hostname、path 构成数组传给 Indexer 进行反序列化。自采集的操作系统指标会带上操作系统类型的字段，操作系统和存储集中后的日志需要带上主机名或者 IP 标识。目前指标数据存入到 ES 中都使用小写，后续可以根据系统人员具体需求优化解析相关日志。

缓冲层（Broker） 使用 Kafka 替代 Redis

在这一层我们主要进行了使用 Kafka 来代替 Redis 的工作。从技术上看虽然在 Elastic 早期官方的指南中推荐使用 Redis，但是后来从产品角度上来看 Redis 毕竟不是专业的消息队列，Redis 做队列最大的问题在于容量受制于内存，且单节点大内存持久化过长，且没有复制情况下整机故障时存储在 Redis 中的数据容易丢失（有副本太浪费因此起初未使用复制）。在平均每天数据量 T 级，每秒接入文档数上亿的情况下，Kafka 的吞吐量和集群模式都比 Redis 更优秀，并且 Kafka 有比较完善的高可用机制，一个 Broker 下线不影响整个集群的运行。Elastic 官方在 blog 上后边也发布了使用 Kafka 作为 ELK broker 的一系列文字。Kafka 作为分布式消息队列，能充分的利用集群资源，每个应用上传日志分配一个 topic，不同系统日志使用自己单独的 topic，Flume 和 Logstash 上送日志和指标走自己单独的 topic，一个 topic 可拥有多个 partition，并且 partition 能合理分配到每个节点上面，采集上来的日志也会均匀的放到 partition 中。

进行 Kafka 整体管控

同时对 Kafka 的 Broker、Topic、ConsumerGroup 和其 Offset 我们自己开发了相应的管控系统提供配置服务、容量性能指标收集、展示和启停维护操作等功能。

进行 Zookeeper 整体管控

我们还针对 Kafka 使用的 Zookeeper 进行了相关配置管理和性能监控功能的开发：

上述 Kafka 和 Zookeeper 的核心微服务代码已经开源，欢迎大家试用：https://github.com/gnuhpc/Kafka-zk-restAPI/tree/0.10.x

处理层（Indexer） Logstash Indexer 后端解析

上篇提到目前我们已经开始逐步开展源端轻量化的工作，因此我们专门申请了一批 cpu 能力较强的机器用作 Logstash Indexer 日志解析服务，agent 前端计划采用 Filebeat/Rsyslog 代替 Logstash 进行日志采集，Filebeat 只做日志采集和多行匹配，日志解析处理集中到 Kafka 后的 Logstash Indexer 来做。初步架构图如下：

相关规则如下：操作系统、标准中间件、数据库运行日志和指标等由于日志规范，Logstash 一个 Indexer 就能通用处理所有 agent 端上送的数据。而应用日志由于日志格式不统一，因此不管是 Flume 还是 Logstash 采集上来的数据，在 Indexer 层上均针对一个系统使用一个（或多个，视处理能力而定）Logstash Indexer 来处理，以达到日志字段解析都在后端执行的目标。在处理数据入 ES 时统一使用按天原则，在 ES 中以应用为单位创建索引，索引按照天来拆分，同一个应用的应用日志存放在同一个 index 模式下。

同时，由于 Logstash 作为后端 Indexer 进行日志解析效率和众多 Logstash 进程管理带来的复杂度，目前我们正积极调研 Hangout

（https://github.com/childe/hangout）

携程开源，我团队为该项目的第二作者）on Docker 以及 StreamSets 替代后端 Logstash 的可能性，以便更高效灵活的处理日志。前者是一个替代 Logstash 的方案，相对 Logstash 功能简单但处理更高效，后者 Streamsets 是一种专门针对传输中数据进行优化的数据处理平台，提供了可视化数据流创建模型，通过开源的方式发行，数据收集器的生命周期可通过管理控制台进行控制，提供了丰富的监视和管理界面。但是它本身也是不支持集群模式，而且目前国内外实际运用到生产环境的案例较少，学习成本较高。

Logstash Indexer 升级

我们针对 Logstash 进行了从 2.x 到 5.x 的升级。新版本 Logstash 性能根据一些测试结果有比较大的提升。另外新版的 Logstash 提供了监控 API 接口，同时 Kibana 的 x-pack montior 也是免费的，这个对管理和查看 Logstash 状态有极大帮助，尤其是对于我们目前多 Logstash Indexer 消费 Kafka 消息的架构下。Logstash 升级相对简单一些，软件层直接进行替换即可，但是由于最新版的有不少参数和配置文件发生变化，所以需要进行目录重规划和重新配置，具体如下：

1. 与老版本不同的是 Logstash 5.X 不同的解析配置文件需要单独放在不同的目录中，因为新版本的 jvm 参数和相关配置都是写在独立的配置文件中而不是像以前作为参数传入，这样可方便对不同的 Indexer 作不同的资源分配，如 cpu、内存等等。同时由于新版本 Logstash 提供了监控 API，需要分配 http 端口进行访问，相同目录配置也会端口冲突导致 Logstash 无法启动，启动命令需要增加 --path.settings 指定到对应的不同配置目录上。

1. 解析配置文件相关参数需要调整，Logstash 新的版本的 Kafka input 插件不再支持 zk_connect、white_list 这种旧 Kafka API 的参数，必须使用新的参数去连接 9092 端口而不是 zookeeper 端口去消费数据。

1. 针对消费不同的 Kafka topic 的数据量设置不同的资源参数，通过修改 jvm.options 分配内存，通过修改 Logstash.yml 设置 cpu 资源和 batch 参数。

1. 使用升级后的 Logstash 发现生产中非 UTF-8 编码的中文日志经过 avro 序列反序列化后有乱码的问题，我们最后修改了 Logstash-input-Kafka 插件的源代码，在

vendor/bundle/jruby/1.9/gems/Logstash-input-Kafka-5.1.8/lib/Logstash/inputs/ Kafka.rb

中修改提供了两个新选项：

(1) charset 指定原先日志的编码，默认不设置为 UTF-8

(2) charset_field 是一个数组，指定哪些 field 需要转码，默认为空，也就是都不转换。

参考：

https://mp.weixin.qq.com/s?__biz=MzU1NDA4NjU2MA==&mid=2247487107&idx=1&sn=59ae4e09c6418cfac534f45e8572a577&chksm=fbe9b74ccc9e3e5aa3894166619833aab6ba4eec9c8099e4b1ea1c3ca54aa4901fed70f2642f&scene=21#wechat_redirect