中國民生銀行天眼日誌平臺架構演進的平凡之路

本文由 【 AI前線】原創，原文連接： t.cn/RYgJ8hD

AI 前線導讀: 「隨着中國民生銀行的 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 上，歡迎你們試用，地址：

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 升級相對簡單一些，軟件層直接進行替換便可，可是因爲最新版的有很多參數和配置文件發生變化，因此須要進行目錄重規劃和從新配置，具體以下：

1. 與老版本不一樣的是 Logstash 5.X 不一樣的解析配置文件須要單獨放在不一樣的目錄中，由於新版本的 jvm 參數和相關配置都是寫在獨立的配置文件中而不是像之前做爲參數傳入，這樣可方便對不一樣的 Indexer 做不一樣的資源分配，如 cpu、內存等等。同時因爲新版本 Logstash 提供了監控 API，須要分配 http 端口進行訪問，相同目錄配置也會端口衝突致使 Logstash 沒法啓動，啓動命令須要增長 --path.settings 指定到對應的不一樣配置目錄上。

2. 解析配置文件相關參數須要調整，Logstash 新的版本的 Kafka input 插件再也不支持 zk_connect、white_list 這種舊 Kafka API 的參數，必須使用新的參數去鏈接 9092 端口而不是 zookeeper 端口去消費數據。

3. 針對消費不一樣的 Kafka topic 的數據量設置不一樣的資源參數，經過修改 jvm.options 分配內存，經過修改 Logstash.yml 設置 cpu 資源和 batch 參數。

4. 使用升級後的 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 升級步驟大體以下：

1. 暫停 Logstash Indexer 日誌數據寫入

2. 關閉集羣 shard allocation

3. 手動執行 POST /_flush?wait_for_ongoing，等到操做結束再返回

4. 手動執行 POST /_flush/synced

5. 關閉全部 ES 集羣節點

6. 執行新版本 Elasticsearch 軟件替換

7. 啓動全部 ES 集羣節點

8. 從新開啓集羣 shard allocation

9. 等待 recovery 完成，集羣 health status 變成 green

10. 從新開啓 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 大數據相關技術人員急缺，我行正在官網上誠招有志於投身到銀行大數據行業並專一於技術的小夥伴，也歡迎聯繫第二做者微信交流關注。

做者介紹：

趙蒙， 工做於中國民生銀行總行信息技術部大數據基礎技術平臺和產品組，天眼日誌平臺負責人，專一於全行分佈式日誌平臺的建設以及 Elasticsearch 在銀行的應用方案落地實施。

黃鵬程， 工做於中國民生銀行總行信息技術部大數據基礎技術平臺和產品組，團隊負責人，負責 Hadoop 平臺的規劃建設和維護工做，參與天眼日誌平臺和大數據管控平臺，微信 gnuhpc。

文喬， 工做於中國民生銀行總行信息技術部大數據基礎技術平臺和產品組，負責行內大數據管控平臺的設計開發，同時參與 Elasticsearch 技術工做。她在 Flume 上亦有所深刻。

關注咱們的微信號"AI前線"，後臺回覆「AI」可得到《AI前線》系列PDF電子書