Apollo+ES源码改造，构建民生银行的ELK日志平台配置管理中心

作者 | 中国民生银行大数据基础平台运维组团队

编辑 | 张婵

随着 IT 业务系统的迅速发展，中国民生银行需要考虑实现一套完整并适用于民生银行的日志文件智能分析与处理的解决方案。本文详细介绍了中国民生银行大数据基础平台运维组团队通过改造 Apollo 和 ES 的源码，构建了自己的天眼实时智能日志管理分析平台。

   背景   

随着中国民生银行的 IT 业务系统的迅速发展，主机、设备、系统、应用软件数量不断增多，业务资源访问、操作量不断增加，对于应用整体系统智能分析与处理的要求不断提高，在解决分布式大数据搜索、日志挖掘和可视化的过程中，需要考虑实现一套完整并适用于民生银行的日志文件智能分析与处理的解决方案。

基于此天眼实时智能日志管理分析平台应运而生，通过日志的收集、传输、储存，对海量系统日志进行集中管理和实时搜索分析，帮助运维人员进行业务实时监控、故障定位及排除、业务趋势分析、安全与合规审计等工作，深度挖掘日志的大数据价值，提升了应用整体系统智能分析与处理效率，达到了汇总、检索、展示应用日志和串联事件、快速定位问题等全方位功能要求。

目前日志平台纳管的服务器超过 1000 台，覆盖了民生银行所有操作系统类型：SuSE Linux（11/12）、AIX（7）、HP_UX（11）和 RedHat（5.5），除了应用日志以外，系统软件日志类型覆盖 DB2、Oracle、Mysql、Redis、Weblogic、Activemq、Kafka、Tomcat 等等，同时采集存储、操作系统、管理口相关指标日志。每天接入日志量在 10T 到 20T 之间，平均日接入量在 15T 左右。

在如此量级的日志接入下，对平台本身吞吐量、端到端全链路的写入延迟、查询响应时间等都提出了比较高的要求，因此对于 ES 集群本身的参数调优成为了一项持续进行的长期性工作，这时 ES 物理节点过多导致的配置文件分散、角色参数差异、版本管理混乱、配置监控缺失等问题就集中暴露了出来。而使用脚本或者文件分发管理又不够直观和友好，出现问题排查困难，易用性较差，也不具备分布式和高可用功能。

为了能够界面化、集中化管理 ES 集群不同角色、不同类型的配置并且在配置修改后能够在 ES 中实时生效，所有配置信息的修改具备规范的权限、流程治理等特性，民生银行天眼 ELK 日志平台最终采用携程开源的 Apollo（阿波罗）作为技术选型，本篇以民生银行天眼日志平台实际需求为中心，逐步展开介绍我们是如何通过 Apollo+ES 源码改造构建民生银行天眼 ELK 日志平台配置管理中心的。

Apollo 功能介绍

Apollo 目前在 GitHub 的 Star 数量超过 10000，社区活跃度和版本更新效率都比较高，首先简单介绍一下 Apollo 本身的功能点和其在天眼 ELK 日志平台配置管理中心中的实际运用。

Apollo 是携程的开源配置管理中心，可以从应用、环境、集群、命名空间 4 个维度集中管理配置，并能够实时推送至客户端，优点如下：

 统一管理不同环境、不同集群的配置

Apollo 提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。同一份代码部署在不同的集群，可以有不同的配置，通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。

由于民生银行开发、测试、生产环境均是网络隔离的，所以在进行 Apollo 部署时我们去掉了 4 个环境标识 DEV、FAT、UAT、PRO 中的后面 3 个，只保留了 DEV 环境，测试和生产均完整的部署一套 Apollo 环境。另外运用集群（cluster）实现了 ES 角色配置文件分离，运用 namespace 实现了 ES 不同种类配置文件分析，这些在后面 Apollo+ES 设计中会详细讲到。

 配置修改实时生效（热发布）

用户在 Apollo 修改完配置并发布后，客户端能实时（1 秒）接收到最新的配置，并通知到应用程序。

这个功能比较诱人，我们在其它项目中也使用到了热发布，但是在 ES 中没有配置，一方面是由于 ES 读取的很多配置的模式都是读且仅读一次，热配置无法生效。另一方面 ES 代码较复杂，其在读取配置文件前后都需要初始化很多参数，很多配置参数是扩散到整个项目代码中的，核心代码、插件代码可能都会有涉及，一些如监听端口配置修改需要重起相关线程模块，实现热配置风险太高，最后热配置在 ES 源码改造过程中我们只是用于配置参数变化的日志输出打印，完成配置生效还是需要重起节点进程。

 版本发布管理

所有的配置发布都有版本概念，从而可以方便地支持配置的回滚。

这个是配置中心基本功能，在日志平台进行 ES 参数优化我们依赖 Apollo 进行版本管理，使用起来比较方便。

 灰度发布

支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。

在日志平台实际应用中我们经常使用灰度发布的功能去验证某些通用参数是否可以配置在角色节点或者数据节点可以单独生效，在 default 集群参数中让某些参数的发布推送到特定的 master 节点或者 data 节点，不过最后根据默认参数全部配置一致原则会将 default 中修改过的参数配置推送到全部的 ES 节点当中。

 权限管理、发布审核、操作审计

应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。所有的操作都有审计日志，可以方便地追踪问题。

在权限控制上生产环境要求必须日志平台 A 岗负责人有最终的发布权限，ES 参数修改对集群整个的稳定性影响比较大，必须将风险降到最低。另外目前日志平台配置管理中心也承担着一些项目组自己开发的工具的配置管理工作，所以单独也进行了权限的划分和处理。

 客户端配置信息监控

可以在界面上方便地看到配置在被哪些实例使用。

这个功能在日志平台中某种程度上也起到了实例心跳检测的功能，同时根据角色的划分可以清楚地看到这个 ES 的逻辑节点配置位置，比如 default 参数肯定是所有节点都会读取，而单独的 master、hot、warm、client 节点只有相关的角色节点才会读取其配置。值得一提的是由于有缓存的功能，可以看到 ES 相关节点读取配置的时间实际上是参数改变后节点第一次读取配置的时间，如果 ES 节点单独重启但是相关参数没有发生变化和发布，那么界面上看到的配置参数读取时间是不会发生改变的。

 提供 Java 和.Net 原生客户端

提供了 Java 和.Net 的原生客户端，方便应用集成，同时提供了 Http 接口，非 Java 和.Net 应用也可以方便地使用。

ES 本身就是通过 Java 语言编写的，所以 通过修改 ES 源码可以比较方便地将 Apollo 客户端集成到 ES 中去。后续我们打算将 Logstash 处理的配置文件也通过 Apollo 纳管，由于 Logstash 是用 ruby 语言，所以可能就会用到其提供的 Http 接口。

 提供开放平台 API

Apollo 自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过 Apollo 出于通