中国民生银行天眼日志平台架构演进的平凡之路

时间 2019-11-16

原文原文链接

本文由【 AI前线】原创，原文连接： t.cn/RYgJ8hD

AI 前线导读: “随着中国民生银行的 IT 业务系统的迅速发展，主机、设备、系统、应用软件数量不断增多，业务资源访问、操做量不断增长，对于应用总体系统智能分析与处理的要求不断提升, 急需创建包含全部应用、系统、存储、设备的统一的日志集中管理平台。本文分享了中国民生银行大数据基础产品团队如何基于 ELK 技术栈构建本身的天眼日志平台以及平台架构优化、升级和演进的过程”。

天眼日志平台功能定位

基于 ELK（Elasticsearch＋Logstash＋Kibana）创建一体化日志平台，提供日志收集、处理、存储、搜索、展现等全方位功能。经过日志的收集、传输、储存，对海量系统日志进行集中管理和准实时搜索分析，帮助运维人员进行业务准实时监控、故障定位及排除、业务趋势分析、安全与合规审计等工做，深度挖掘日志的大数据价值。前端

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

早期的平台架构git

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

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

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

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

天眼日志平台目前已经接入 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 组件和核心组件的过程当中，发现其没法彻底知足咱们的需求，例如：

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

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

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

github.com/tinawenqiao…，分支名 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 的核心微服务代码已经开源，欢迎你们试用：github.com/gnuhpc/Kafk…

处理层（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

（github.com/childe/hang…）

携程开源，我团队为该项目的第二做者）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 升级相对简单一些，软件层直接进行替换便可，可是因为最新版的有很多参数和配置文件发生变化，因此须要进行目录重规划和从新配置，具体以下：

与老版本不一样的是 Logstash 5.X 不一样的解析配置文件须要单独放在不一样的目录中，由于新版本的 jvm 参数和相关配置都是写在独立的配置文件中而不是像之前做为参数传入，这样可方便对不一样的 Indexer 做不一样的资源分配，如 cpu、内存等等。同时因为新版本 Logstash 提供了监控 API，须要分配 http 端口进行访问，相同目录配置也会端口冲突致使 Logstash 没法启动，启动命令须要增长 --path.settings 指定到对应的不一样配置目录上。
解析配置文件相关参数须要调整，Logstash 新的版本的 Kafka input 插件再也不支持 zk_connect、white_list 这种旧 Kafka API 的参数，必须使用新的参数去链接 9092 端口而不是 zookeeper 端口去消费数据。
针对消费不一样的 Kafka topic 的数据量设置不一样的资源参数，经过修改 jvm.options 分配内存，经过修改 Logstash.yml 设置 cpu 资源和 batch 参数。
使用升级后的 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 须要转码，默认为空，也就是都不转换。

具体代码参见

github.com/logstash-pl…

下篇咱们将介绍咱们的存储层（Storage）和展现层（Presentation）的技术架构以及咱们的工做，最后咱们将展现目前的应用场景并作出总结。另外中国民生银行数据呈井喷式增加，ELK、Hadoop、Spark 大数据相关技术人员急缺，我行官网正诚招有志于投身到银行大数据行业并专一于技术的小伙伴，也欢迎联系关注。

做者介绍：

赵蒙， 工做于中国民生银行总行信息技术部大数据基础技术平台和产品组，天眼日志平台负责人，专一于全行分布式日志平台的建设以及 Elasticsearch 在银行的应用方案落地实施。

黄鹏程， 工做于中国民生银行总行信息技术部大数据基础技术平台和产品组，团队负责人，负责 Hadoop 平台的规划建设和维护工做，参与天眼日志平台和大数据管控平台，微信 gnuhpc。

文乔， 工做于中国民生银行总行信息技术部大数据基础技术平台和产品组，负责行内大数据管控平台的设计开发，同时参与 Elasticsearch 技术工做。她在 Flume 上亦有所深刻。

中国民生银行天眼日志平台架构演进的平凡之路（下篇）

存储层（Storage）

咱们的存储层采用 Elasticsearch。采用热数据进入 SSD、温数据进入 SATA 盘，冷数据 snapshot 至 HDFS 的层次化存储结构。最先天眼日志平台 Elasticsearch 和 Logstash 使用的是 2.3.5 版本，基于 Kibana4 做可视化展示。因为 ES 社区很是活跃，ELK 版本发布特别频繁，在不到一年的时间里已经从 2.X 跳到了 5.X。5.X 版本的 lucene 更新到了 6.2，搜索方面应该会有比较大的性能提高。同时官方推荐新的 ES 性能更加稳定，ELK 整个技术栈产品都有很大的变化和功能的扩展。升级时官方资料显示 ES 5.X 已经比较稳定，咱们观察一段时间后最后咱们使用的版本是 5.5.0 版本，另外 5.X ES 优化了 indexing 也是咱们很期待的。

ES 集群升级

采用官方提供的离线升级方式，直接用新版本软件替换掉老版本并保证原数据可用。升级前使用 ES migration 迁移插件检查升级前潜在的问题

A. node 属性

新版本一些 node 属性名称发生了变化，如 node.box_type 改为 node.attr.box_type。新版本没有 client node 了，分为 master node，data node，ingest node，coordinating only node，设置方法分别是：

B. index settings

ES 从 5.0 开始 index 相关参数均不在 config 文件里配置，而须要在集群索引级别中进行设置（除了 index.codec 等相似实例级别能够在 node 级别设置）。注意执行下面这条语句会报错，由于这几个参数都是不能动态修改的。

C. 重命名设置

5.X 参数名称变化较大，bootstrap.mlockall 改成 bootstrap.memory_lock， discovery.zen.initial_ping_timeout 改成 discovery.zen.ping_timeout，默认是 3s，新版本去掉了 discovery.zen.initial_ping_timeout 和 discovery.zen.ping.timeout 两个设置。

D. 参数变化

discovery.zen.ping.multicast 参数已经废弃，在 5.X 里去掉了多播，用单播或者 cloud discovery 插件，action.disable_delete_all_indices 改为 action.destructive_requires_name，须要用 cluster update API 修改：

5.X 里没有这个 path.work: 配置，ES 5.X 里 translog 的 flush 参数只有

index.translog.flush_threshold_size。

ES 升级步骤大体以下：

暂停 Logstash Indexer 日志数据写入
关闭集群 shard allocation
手动执行 POST /_flush?wait_for_ongoing，等到操做结束再返回
手动执行 POST /_flush/synced
关闭全部 ES 集群节点
执行新版本 Elasticsearch 软件替换
启动全部 ES 集群节点
从新开启集群 shard allocation
等待 recovery 完成，集群 health status 变成 green
从新开启 Logstash Indexer 日志数据写入

ES 集群升级之后一些相关插件和工具也须要捆绑升级，head 插件须要升级到 5.X，原来的 kopf 可视化监控插件再也不可用，咱们使用 cerebro 代替 kopf，cerebro 和老版本的 kopf 插件页面几乎如出一辙，功能上能够彻底替代。同时咱们计划采用最新版本引入的 cross-cluster 来实现跨中心跨集群访问功能。

IK 兼容性

升级过程当中固然不多是一路顺风的，期间遇到了不少问题，现分享一个比较有表明性的“坑”给你们分享。

ES 新版本程序替换重启后，状态一直是 red，查看日志，有大量关于 ik 的报错，找不到 ik 的分析器，以下所示：

在升级以前，咱们已从 Github 的 ik 项目上得知，在 5.0 以后，ik 被更名，截图以下：

可是对于已有的索引，某些字段的分析器指定的是 ik，例如上图报错中索引 l-Kibana-2017.08 是升级前创建的索引，_all 字段指定的分析器是 ik，而升级后改名为 ik_smart，所以报找不到 ik 分析器的错误。虽然关闭索引以后修改索引的 analyzer 也能够实现分词器名称的修改（在不关闭索引的状况下直接修改分析器会报错），但因为索引众多，为了更快的实现兼容，咱们修改 Elasticsearch-analysis-ik 源码解决，使得最新版 ik 插件也能支持名为 ik 的分析器。

(https://github.com/medcl/Elasticsearch-analysis-ik/pull/411/commits/63326ca322ccb8c1bd3662ab7c0bfd38a86a53cb）

存储层各个组件升级之后效果明显，最直观的感觉就是以前 master 节点随着时间的推移 heap 内存使用率持续增加的问题没有了。实际上存储层不只仅是对 ELK 进行了升级，还进行了调整底层索引组织结构，对冗余数据进行清理，开发经常使用工具脚本，小规模资源扩容等等一系列工做，因此通过测试和实际使用评估，升级后平台更加稳定，查询更加高效。

冷热数据控制

同时针对日志量数据量激增的状况，新架构引入了 SSD 来提高 ES 的读写性能。单台 ES 存储有 2 块 SD 盘和若干 SATA 盘，因此每台 ES server 都启动了 3 个 ES 节点，2 个 hot 节点和 1 个 warm 节点。Indexer 中指配置了 hot 节点的端口，经过 ES 中的模板定义保证明时数据只写入 hot 节点。

经过 ES 官方推荐的 curator 工具定时将数据从 hot 节点搬迁到 cold 节点，SSD 数据保留周期为一周。curator 的 action 配置文件以下：

生命周期管理上天眼日志平台实施日志数据按期导入到大数据平台 hdfs 策略，日志数据保留一个月，一个月前的数据根据定时任务按期导入到大数据平台中，ELK 中再也不保存，大数据平台的日志、指标数据保存期限是一年。注意：数据冷热分离过程当中使用到的 curator 也必须使用最新的版本才可使用，在集群升级完毕之后也须要从新安装。

展现层（Presentation）

Kibana 升级

Kibana5 可视化方式更加灵活、丰富，提供了更加多的组件和监控可视化视图，更多的功能和更好的用户体验对于平台使用者有极大的吸引力。Kibana 升级比较简单，可是因为默认新版本无分词的 raw 字段已经变成了 keyword 字段，因此 Kibana 的 indices 属性须要刷新，同时以前创建的 visualize 也须要进行字段属性调整。新版本的 Kibana 确实增长了丰富的视图和展示功能，页面显示也更加美观。

多租户访问控制和数据脱敏显示

因为 X-pack security 模块是收费的，咱们经过自主开发的方式使用 Kibana proxy（地址 https://github.com/gnuhpc/Kibana-multitenant-proxy）实现了 Kibana 权限控制和数据显示脱敏。目前权限控制到索引层，即一个用户只能够访问指定的 Index，若是访问其余 Index 则在 Kibana 上没法显示。同时因为银行业的数据敏感，咱们还提供了在配置文件中设置脱敏关键字，日志入 ES 时不脱敏，在 Kibana 上查询时加密显示的功能。Kibana-proxy 脱敏显示的效果以下：

应用场景

日志定位搜索

能经过关键字和简单符号解决搜索问题，避免使用复杂正则，有比较好的用户搜索体验。当多台服务器输出日志的时候，须要可以快速发现这个究竟请求落到哪台服务器上，报了什么样的错误，为何其余服务器上不会报错等问题。有时也须要同时可以平行关联查询某些服务器日志才能作出问题判断，好比同时查询主备库日志来判断某一点时刻数据库是否同步。

运营分析支持

对日志数据进行挖掘，提取有价值的数据造成图表进行展现。Kibana 提供了丰富的可视化图表展示，方便从应用角度对于业务系统的整体日均访问量状况、重要功能的访问进行统计；从交易角度显示系统的整体交易量、交易成功率和延迟，多维度支持业务运营工做。

监控统计分析

按期对告警数据进行分类统计分析，为监控应用程序性能预估、流程监控、任务流检测、推广部署等提供数据支撑。对于生产环境的相关技术组件覆盖状况进行统计、趋势等分析，多维度了解各类技术组件生产实际使用状况。

应用统一分析视图

在 Kibana 升级后咱们在 dashboard 之上封装了一层做业整体概况显示，将 A、B、C、D 类系统接入状况进行统一展现，造成以应用为维度的视图分析模板，新接入应用只须要直接套用模板便可无需进行单独配置，模板包含业务交易、操做系统、中间件、数据库等日志统一信息，扩展成为应用系统一分析视图。

总结与展望

通过不到两年的建设，经过不一样的架构调整和设计开发，咱们基于 ELK 的日志平台对于以下功能目标均按预期实现：

数据定位准确：经过对日志进行细颗粒度字段解析尽量知足实现不一样场景下日志集中存储和管理的业务需求，方便进行查询。
写入和查询高效：经过对 ELK 平台升级和集群内存调优、合理的分片配置、冷热数据分离最大程度地提升日志的写入和查询效率。
高可用部署：经过 ELK 平台集群高可用设计部署实现故障切换时日志平台系统自身可用，服务不中断。
安全可靠：经过自主开发权限控制和数据脱敏，保证了平台日志数据的安全性和可靠性。

架构持续在演进，技术永远在前行。客观地讲，目前该平台的每一次架构变迁并不是是最正确的选择或者是最优的解决方案，如何让“平凡之路”走得不平凡，咱们民生银行大数据基础技术平台和产品团队一直在孜孜不倦地探索中。咱们的终极目标就如平台的名字同样，可让开发和运维工程师随时主动经过“天眼”实时查看系统情况，对系统状况了如指掌，对事故隐患明察秋毫，对性能容量胸有成竹，促使经过天眼日志平台进行日志接入和管理成为生产运维的重要组成部分。另外中国民生银行数据呈井喷式增加，ELK、Hadoop、Spark 大数据相关技术人员急缺，我行正在官网上诚招有志于投身到银行大数据行业并专一于技术的小伙伴，也欢迎联系第二做者微信交流关注。

做者介绍：

关注咱们的微信号"AI前线"，后台回复“AI”可得到《AI前线》系列PDF电子书