民生銀行天眼日志平臺方案

1、 民生銀行天眼日志平臺方案AI前線 微信號 ai-front功能介紹 InfoQ十年沉淀，為千萬技術(shù)人打造的專屬AI公眾號。追蹤技術(shù)新趨勢，跟蹤頭部科技企業(yè)發(fā)展和傳統(tǒng)產(chǎn)業(yè)技術(shù)升級落地案例。囊括網(wǎng)站和近萬人的機(jī)器學(xué)習(xí)知識交流社群。導(dǎo)讀: 隨著中國民生銀行的 IT 業(yè)務(wù)系統(tǒng)的迅速發(fā)展，主機(jī)、設(shè)備、系統(tǒng)、應(yīng)用軟件數(shù)量不斷增多，業(yè)務(wù)資源訪問、操作量不斷增加，對于應(yīng)用整體系統(tǒng)智能分析與處理的要求不斷提高, 急需建立包含所有應(yīng)用、系統(tǒng)、存儲、設(shè)備的統(tǒng)一的日志集中管理平臺。本文分享了中國民生銀行大數(shù)據(jù)基礎(chǔ)產(chǎn)品團(tuán)隊(duì)如何基于 ELK 技術(shù)棧構(gòu)建自己的天眼日志平臺以及平臺架構(gòu)優(yōu)化、升級和演進(jìn)的過程?；?ELK（

2、ElasticsearchLogstashKibana）建立一體化日志平臺，提供日志收集、處理、存儲、搜索、展示等全方位功能。通過日志的收集、傳輸、儲存，對海量系統(tǒng)日志進(jìn)行集中管理和準(zhǔn)實(shí)時搜索分析，幫助運(yùn)維人員進(jìn)行業(yè)務(wù)準(zhǔn)實(shí)時監(jiān)控、故障定位及排除、業(yè)務(wù)趨勢分析、安全與合規(guī)審計等工作，深度挖掘日志的大數(shù)據(jù)價值。目前接入天眼日志平臺的日志覆蓋了應(yīng)用、操作系統(tǒng)、數(shù)據(jù)庫、中間件、存儲和管理口日志數(shù)據(jù)，同時對于各個模塊部分指標(biāo)進(jìn)行采集和存儲。早期的平臺架構(gòu) 早期的天眼日志平臺使用了原始的 ELK 三層架構(gòu)模式：多個獨(dú)立的 Logstash agent(shipper) 負(fù)責(zé)收集不同來源的數(shù)據(jù)，一個中心 a

3、gent(Indexer) 負(fù)責(zé)匯總和分析數(shù)據(jù)，在中心 agent 前的 Broker 使用 Redis 作為緩沖區(qū)，中心 agent 后的 Elasticsearch（后簡稱 ES）用于存儲和搜索數(shù)據(jù)，應(yīng)用可以采用定制化的 Kibana 提供豐富的圖表展示，也可以根據(jù) ES 的 RESTful API 行開發(fā)定制。采集層：shipper 表示日志收集，使用 Logstash 收集各種來源的數(shù)據(jù)，啟動時隨機(jī)在 Redis 服務(wù)器列表中選擇一個服務(wù)器進(jìn)行對 Broker 的連接。緩沖層：Broker 作為遠(yuǎn)程 shipper 與中心 Indexer 之間的緩沖區(qū)，使用 Redis 實(shí)現(xiàn)，一是可以

4、提高系統(tǒng)的性能，二是可以提高系統(tǒng)的可靠性，當(dāng)中心 Indexer 提取數(shù)據(jù)失敗時，數(shù)據(jù)保存在 Redis 中而不至于丟失。處理層： 中心 Indexer 也采用 Logstash，從 Broker 中提取數(shù)據(jù)，可以執(zhí)行相關(guān)的分析和處理 (filter)；一個 Indexer 會輪詢從多個 Redis 進(jìn)行數(shù)據(jù)獲取，這樣防止了一個 Indexer 宕后對應(yīng)的 Broker 無人處理。存儲層：Elasticsearch 用于存儲最終的數(shù)據(jù)，并提供搜索功能。展示層：Kibana 提供一個簡單、豐富的 web 界面，數(shù)據(jù)來自于 Elasticsearch，支持各種查詢、統(tǒng)計和展示。經(jīng)過一年多的時間，隨

5、著日志平臺的發(fā)展，接入日志量呈幾何級增長，日志寫入請求給服務(wù)器帶來很大的性能壓力，同時應(yīng)用運(yùn)維人員對平臺的需求越來越復(fù)雜和多樣性，前期架構(gòu)設(shè)計帶來的各個層次的一系列問題都逐步暴露出來：采集層基于 Logstash 實(shí)現(xiàn)的 agent 平臺類別受限，無法支持 AIX、HP_UNIX 等 Unix 操作系統(tǒng)，同時通用的開源產(chǎn)品 Flume 功能比較單一，無法滿足我們常規(guī)的日志收集需求。agent 日志解析對資源消耗較多，迫切需要將日志的分析與處理提升到后端處理層。緩沖層無法提供分布式消息隊(duì)列服務(wù)，同時容量和效率亟待提高。存儲層原始版本組件功能有缺陷，版本迭代較快，需要集中升級。展示層缺乏場景統(tǒng)一管

6、理入口，各個應(yīng)用場景相互獨(dú)立不具備通用性。基于上述問題，我們設(shè)計了新的架構(gòu)。天眼日志平臺目前已經(jīng)接入 58 個應(yīng)用系統(tǒng)，其中 A、B 類重要核心應(yīng)用 44 個，覆蓋了 500+ 的服務(wù)器，日均 5T 的數(shù)據(jù)寫入量，可以很好地支持運(yùn)維應(yīng)用人員對日志文件進(jìn)行智能分析與處理，達(dá)到了平臺日志收集、處理、存儲、搜索、展示等全方位功能要求。下面我們分別對這個架構(gòu)中我們所做的一些工作和大家進(jìn)行分享。采集層（Agent） 適配 Unix 操作系統(tǒng) 在 Agent 層，為了更好地適配更多樣的操作系統(tǒng)，我們主要采用 Logstash 和 Flume 進(jìn)行日志和指標(biāo)采集，在這個過程中對 Flume 進(jìn)行了較多的定制

7、，并進(jìn)行了社區(qū)回饋。首先，我們在 Linux 操作系統(tǒng)上采用 Logstash 進(jìn)行日志的采集和初步解析。但是由于 Logstash 的 jvm 環(huán)境不是標(biāo)準(zhǔn)的 jdk，在 HP_UNIX 和 AIX 操作系統(tǒng) Logstash 無法運(yùn)行，所以這兩類操作系統(tǒng)使用 Flume 進(jìn)行日志采集。所有 agent 的解析文件都是通用的，Logstash 一類通用，F(xiàn)lume 一類通用。如果通用日志的系統(tǒng)上（主要是中間件）同時需要采集應(yīng)用日志，Logstash 需要配置將應(yīng)用日志和系統(tǒng)日志的采集邏輯都包含進(jìn)去，原則就是一臺機(jī)器采集日志的 Logstash/Flume agent 只啟動一個進(jìn)程。而對于操

8、作系統(tǒng)的 syslog 和存儲設(shè)備日志的采集方式是集中采集，使用單獨(dú)的 Logstash agent 進(jìn)行解析上送。Flume 我們最初使用的版本是 Apache Flume 1.6，在使用 Taildir Source 組件和核心組件的過程中，發(fā)現(xiàn)其無法完全滿足我們的需求，例如：若 filegroup 路徑中包含正則表達(dá)式，則無法獲取文件的完整路徑，在日志入到 Elasticsearch 后無法定位日志的路徑；Taildir Source 不支持將多行合并為一個 event，只能一行一行讀取文件；filegroup 配置中不支持目錄包含正則表達(dá)式，不便配置包含多個日期并且日期自動增長的目錄，

9、例如 /app/logs/yyyymmdd/appLog.log；在使用 Host Interceptor 時，發(fā)現(xiàn)只能保留主機(jī)名或者是 IP，二者無法同時保留。在研究 Flume 源碼之后，我們在源碼上擴(kuò)展開發(fā)。截至目前，我們?yōu)殚_源社區(qū)貢獻(xiàn)了如下 4 個 Patch，其中 FLUME-2955 已被社區(qū) Merge 并在 1.7 版本中發(fā)布。有關(guān) 4 個 Patch 的詳細(xì)細(xì)節(jié)介紹請參見 HYPERLINK /s?_biz=MzU1NDA4NjU2MA=&mid=2247487029&idx=1&sn=7df9b8b70cceda632a5a78b0b89d448b&scene=21 l w

10、echat_redirect t _blank 擁抱開源，回饋社區(qū)：民生銀行 Flume 源碼貢獻(xiàn)實(shí)踐。另外我們在 Github 上開放了一個版本，將 FLUME-2960/2961/3187 三個 Patch 合并到 Flume 1.7 上，歡迎大家試用，地址：/tinawenqiao/flume，分支名 trunk-cmbc。Flume 配置樣例如下：源端采集 Agent 輕量化 隨著日志接入工作的不斷推進(jìn)，日志解析都是在 agent 端進(jìn)行的弊病顯露出來。由于 Logstash 是使用 Java 編寫，插件是使用 jruby 編寫，又需要 jvm 環(huán)境運(yùn)行，對服務(wù)器的資源要求會比較高。同

11、時 Logstash 在使用 filter/grok 插件處理復(fù)雜的日志字段抽取和預(yù)處理時，正則解析會耗費(fèi)大量的 cpu 資源，在初始啟動的一瞬間偶爾會沖破 cpu 監(jiān)控報警閥值，有可能影響生產(chǎn)服務(wù)器。雖然目前還沒發(fā)現(xiàn)對應(yīng)用產(chǎn)生實(shí)際負(fù)面影響（agent 有監(jiān)控腳本自殺機(jī)制），但是導(dǎo)致應(yīng)用運(yùn)維人員會非常緊張，在后來的架構(gòu)演進(jìn)中，我們正逐步取消源端解析而改為后臺解析。隨著 Elastic 技術(shù)堆棧的發(fā)展，出現(xiàn)了 Filebeat。Filebeat 是 Beat 成員之一，基于 Go 語言編寫，無任何依賴，比 Logstash 更加輕量，非常適合安裝在生產(chǎn)機(jī)器上，不會帶來過高的資源占用。對比測試中我

12、們創(chuàng)建了 1 個 G 的日志數(shù)據(jù)，不做正則解析，在分配同樣資源的情況下，單線程 logtash 啟動 cpu 瞬間飚高到 80%，后面基本上在 60% 左右，63s 處理完畢，F(xiàn)ilebeat 啟動時 cpu 瞬間在 40% 左右，之后在 20% 左右，15s 處理完畢。從結(jié)果上來看不管是性能還是資源占比 Filebeat 都比 Logstash 要好上不少。在后期演進(jìn)中，我們逐步在新架構(gòu)中將日志解析的工作放在了后端進(jìn)行，只需要 Filebeat 將收集的日志整合原樣上送即可。Agent 統(tǒng)一管控和性能監(jiān)控 由于上一代原始架構(gòu)平臺部署的 agent 缺乏統(tǒng)一管理功能，相關(guān)配置信息均需要手工實(shí)施

13、，自動化程度較弱，也無法與其他系統(tǒng)關(guān)聯(lián)。對此我們在新的日志平臺架構(gòu)下依賴大數(shù)據(jù)管控平臺完成相關(guān)自動化需求，大數(shù)據(jù)管控平臺是我們大數(shù)據(jù)基礎(chǔ)產(chǎn)品團(tuán)隊(duì)自主開發(fā)的一套對大數(shù)據(jù)集群和天眼日志平臺中 agent 統(tǒng)一運(yùn)維管控的項(xiàng)目，具備智能服務(wù)發(fā)現(xiàn)和服務(wù)器管理功能。大數(shù)據(jù)管控平臺上線實(shí)現(xiàn)了日志平臺 agent 的自動化部署、點(diǎn)擊觸發(fā)啟停和監(jiān)控可視化，監(jiān)控可視化通過 Filebeat 和 Flume 上送心跳信息到 Kafka 上，在 Storm 集群上開發(fā)拓?fù)涑绦蛳M(fèi) Kafka 心跳信息存入到大數(shù)據(jù)管控平臺的 MySQL 數(shù)據(jù)庫中進(jìn)行展示。另外通過大數(shù)據(jù)管控平臺與工單系統(tǒng)、服務(wù)目錄、CMDB 系統(tǒng)進(jìn)行聯(lián)

14、動，日志平臺本身只充當(dāng)基礎(chǔ)框架，統(tǒng)一認(rèn)證權(quán)限添加、元數(shù)據(jù)信息下發(fā)、工單數(shù)據(jù)流處理都通過管控平臺頁面 agent 配置文件的集群模塊化錄入和上傳來實(shí)現(xiàn)。在 Agent 資源消耗方面，除了進(jìn)行必要的優(yōu)化手段外，我們還在部署 agent 的同時配套配置 agent 進(jìn)程監(jiān)控，由集中監(jiān)控平臺進(jìn)行統(tǒng)一部署，同時在 agent 端部署一個 crontab 腳本，發(fā)現(xiàn)監(jiān)控報警后即刻將占用較高資源（cpu、內(nèi)存、存儲）的 agent 進(jìn)程殺掉，避免采集 agent 對應(yīng)用系統(tǒng)性能造成影響。明確日志規(guī)范 在應(yīng)用日志規(guī)范上，我們規(guī)定應(yīng)用日志中要求必須帶時間戳，這個時間戳在 agent 進(jìn)行采集時會作為默認(rèn)的 ti

15、mestamp。Logstash agent 需要增加應(yīng)用英文簡稱，F(xiàn)lume agent 需要使用 avro 序列化方式在 head 頭里增加 appname、hostname、path 構(gòu)成數(shù)組傳給 Indexer 進(jìn)行反序列化。自采集的操作系統(tǒng)指標(biāo)會帶上操作系統(tǒng)類型的字段，操作系統(tǒng)和存儲集中后的日志需要帶上主機(jī)名或者 IP 標(biāo)識。目前指標(biāo)數(shù)據(jù)存入到 ES 中都使用小寫，后續(xù)可以根據(jù)系統(tǒng)人員具體需求優(yōu)化解析相關(guān)日志。緩沖層（Broker） 使用 Kafka 替代 Redis 在這一層我們主要進(jìn)行了使用 Kafka 來代替 Redis 的工作。從技術(shù)上看雖然在 Elastic 早期官方的指南

16、中推薦使用 Redis，但是后來從產(chǎn)品角度上來看 Redis 畢竟不是專業(yè)的消息隊(duì)列，Redis 做隊(duì)列最大的問題在于容量受制于內(nèi)存，且單節(jié)點(diǎn)大內(nèi)存持久化過長，且沒有復(fù)制情況下整機(jī)故障時存儲在 Redis 中的數(shù)據(jù)容易丟失（有副本太浪費(fèi)因此起初未使用復(fù)制）。在平均每天數(shù)據(jù)量 T 級，每秒接入文檔數(shù)上億的情況下，Kafka 的吞吐量和集群模式都比 Redis 更優(yōu)秀，并且 Kafka 有比較完善的高可用機(jī)制，一個 Broker 下線不影響整個集群的運(yùn)行。Elastic 官方在 blog 上后邊也發(fā)布了使用 Kafka 作為 ELK broker 的一系列文字。Kafka 作為分布式消息隊(duì)列，能充

17、分的利用集群資源，每個應(yīng)用上傳日志分配一個 topic，不同系統(tǒng)日志使用自己單獨(dú)的 topic，F(xiàn)lume 和 Logstash 上送日志和指標(biāo)走自己單獨(dú)的 topic，一個 topic 可擁有多個 partition，并且 partition 能合理分配到每個節(jié)點(diǎn)上面，采集上來的日志也會均勻的放到 partition 中。進(jìn)行 Kafka 整體管控 同時對 Kafka 的 Broker、Topic、ConsumerGroup 和其 Offset 我們自己開發(fā)了相應(yīng)的管控系統(tǒng)提供配置服務(wù)、容量性能指標(biāo)收集、展示和啟停維護(hù)操作等功能。進(jìn)行 Zookeeper 整體管控 我們還針對 Kafka 使

18、用的 Zookeeper 進(jìn)行了相關(guān)配置管理和性能監(jiān)控功能的開發(fā)：上述 Kafka 和 Zookeeper 的核心微服務(wù)代碼已經(jīng)開源，歡迎大家試用：/gnuhpc/Kafka-zk-restAPI/tree/0.10.x處理層（Indexer） Logstash Indexer 后端解析 上篇提到目前我們已經(jīng)開始逐步開展源端輕量化的工作，因此我們專門申請了一批 cpu 能力較強(qiáng)的機(jī)器用作 Logstash Indexer 日志解析服務(wù)，agent 前端計劃采用 Filebeat/Rsyslog 代替 Logstash 進(jìn)行日志采集，F(xiàn)ilebeat 只做日志采集和多行匹配，日志解析處理集中到

19、Kafka 后的 Logstash Indexer 來做。初步架構(gòu)圖如下：相關(guān)規(guī)則如下：操作系統(tǒng)、標(biāo)準(zhǔn)中間件、數(shù)據(jù)庫運(yùn)行日志和指標(biāo)等由于日志規(guī)范，Logstash 一個 Indexer 就能通用處理所有 agent 端上送的數(shù)據(jù)。而應(yīng)用日志由于日志格式不統(tǒng)一，因此不管是 Flume 還是 Logstash 采集上來的數(shù)據(jù)，在 Indexer 層上均針對一個系統(tǒng)使用一個（或多個，視處理能力而定）Logstash Indexer 來處理，以達(dá)到日志字段解析都在后端執(zhí)行的目標(biāo)。在處理數(shù)據(jù)入 ES 時統(tǒng)一使用按天原則，在 ES 中以應(yīng)用為單位創(chuàng)建索引，索引按照天來拆分，同一個應(yīng)用的應(yīng)用日志存放在同一個

20、 index 模式下。同時，由于 Logstash 作為后端 Indexer 進(jìn)行日志解析效率和眾多 Logstash 進(jìn)程管理帶來的復(fù)雜度，目前我們正積極調(diào)研Hangout（/childe/hangout）攜程開源，我團(tuán)隊(duì)為該項(xiàng)目的第二作者）on Docker 以及 StreamSets 替代后端 Logstash 的可能性，以便更高效靈活的處理日志。前者是一個替代 Logstash 的方案，相對 Logstash 功能簡單但處理更高效，后者 Streamsets 是一種專門針對傳輸中數(shù)據(jù)進(jìn)行優(yōu)化的數(shù)據(jù)處理平臺，提供了可視化數(shù)據(jù)流創(chuàng)建模型，通過開源的方式發(fā)行，數(shù)據(jù)收集器的生命周期可通過管理控

21、制臺進(jìn)行控制，提供了豐富的監(jiān)視和管理界面。但是它本身也是不支持集群模式，而且目前國內(nèi)外實(shí)際運(yùn)用到生產(chǎn)環(huán)境的案例較少，學(xué)習(xí)成本較高。Logstash Indexer 升級 我們針對 Logstash 進(jìn)行了從 2.x 到 5.x 的升級。新版本 Logstash 性能根據(jù)一些測試結(jié)果有比較大的提升。另外新版的 Logstash 提供了監(jiān)控 API 接口，同時 Kibana 的 x-pack montior 也是免費(fèi)的，這個對管理和查看 Logstash 狀態(tài)有極大幫助，尤其是對于我們目前多 Logstash Indexer 消費(fèi) Kafka 消息的架構(gòu)下。Logstash 升級相對簡單一些，軟件

22、層直接進(jìn)行替換即可，但是由于最新版的有不少參數(shù)和配置文件發(fā)生變化，所以需要進(jìn)行目錄重規(guī)劃和重新配置，具體如下：與老版本不同的是 Logstash 5.X 不同的解析配置文件需要單獨(dú)放在不同的目錄中，因?yàn)樾掳姹镜?jvm 參數(shù)和相關(guān)配置都是寫在獨(dú)立的配置文件中而不是像以前作為參數(shù)傳入，這樣可方便對不同的 Indexer 作不同的資源分配，如 cpu、內(nèi)存等等。同時由于新版本 Logstash 提供了監(jiān)控 API，需要分配 http 端口進(jìn)行訪問，相同目錄配置也會端口沖突導(dǎo)致 Logstash 無法啟動，啟動命令需要增加 -path.settings 指定到對應(yīng)的不同配置目錄上。解析配置文件相關(guān)參

23、數(shù)需要調(diào)整，Logstash 新的版本的 Kafka input 插件不再支持 zk_connect、white_list 這種舊 Kafka API 的參數(shù)，必須使用新的參數(shù)去連接 9092 端口而不是 zookeeper 端口去消費(fèi)數(shù)據(jù)。針對消費(fèi)不同的 Kafka topic 的數(shù)據(jù)量設(shè)置不同的資源參數(shù)，通過修改 jvm.options 分配內(nèi)存，通過修改 Logstash.yml 設(shè)置 cpu 資源和 batch 參數(shù)。使用升級后的 Logstash 發(fā)現(xiàn)生產(chǎn)中非 UTF-8 編碼的中文日志經(jīng)過 avro 序列反序列化后有亂碼的問題，我們最后修改了 Logstash-input-Kafk

24、a 插件的源代碼，在vendor/bundle/jruby/1.9/gems/Logstash-input-Kafka-5.1.8/lib/Logstash/inputs/ Kafka.rb中修改提供了兩個新選項(xiàng)：(1) charset 指定原先日志的編碼，默認(rèn)不設(shè)置為 UTF-8(2) charset_field 是一個數(shù)組，指定哪些 field 需要轉(zhuǎn)碼，默認(rèn)為空，也就是都不轉(zhuǎn)換。具體代碼參見/logstash-plugins/logstash-input-kafka/pull/222下篇我們將介紹我們的存儲層（Storage）和展示層（Presentation）的技術(shù)架構(gòu)以及我們的工作，

25、最后我們將展示目前的應(yīng)用場景并做出總結(jié)。另外中國民生銀行數(shù)據(jù)呈井噴式增長，ELK、Hadoop、Spark 大數(shù)據(jù)相關(guān)技術(shù)人員急缺，我行官網(wǎng)正誠招有志于投身到銀行大數(shù)據(jù)行業(yè)并專注于技術(shù)的小伙伴，也歡迎聯(lián)系關(guān)注。作者介紹： 趙蒙， 工作于中國民生銀行總行信息技術(shù)部大數(shù)據(jù)基礎(chǔ)技術(shù)平臺和產(chǎn)品組，天眼日志平臺負(fù)責(zé)人，專注于全行分布式日志平臺的建設(shè)以及 Elasticsearch 在銀行的應(yīng)用方案落地實(shí)施。黃鵬程， 工作于中國民生銀行總行信息技術(shù)部大數(shù)據(jù)基礎(chǔ)技術(shù)平臺和產(chǎn)品組，團(tuán)隊(duì)負(fù)責(zé)人，負(fù)責(zé) Hadoop 平臺的規(guī)劃建設(shè)和維護(hù)工作，參與天眼日志平臺和大數(shù)據(jù)管控平臺，微信 gnuhpc。文喬， 工作于中國

26、民生銀行總行信息技術(shù)部大數(shù)據(jù)基礎(chǔ)技術(shù)平臺和產(chǎn)品組，負(fù)責(zé)行內(nèi)大數(shù)據(jù)管控平臺的設(shè)計開發(fā)，同時參與 Elasticsearch 技術(shù)工作。她在 Flume 上亦有所深入。中國民生銀行天眼日志平臺架構(gòu)演進(jìn)的平凡之路（下篇）存儲層（Storage） 我們的存儲層采用 Elasticsearch。采用熱數(shù)據(jù)進(jìn)入 SSD、溫數(shù)據(jù)進(jìn)入 SATA 盤，冷數(shù)據(jù) snapshot 至 HDFS 的層次化存儲結(jié)構(gòu)。最早天眼日志平臺 Elasticsearch 和 Logstash 使用的是 2.3.5 版本，基于 Kibana4 作可視化展現(xiàn)。由于 ES 社區(qū)非常活躍，ELK 版本發(fā)布特別頻繁，在不到一年的時間里已經(jīng)

27、從 2.X 跳到了 5.X。5.X 版本的 lucene 更新到了 6.2，搜索方面應(yīng)該會有比較大的性能提升。同時官方推薦新的 ES 性能更加穩(wěn)定，ELK 整個技術(shù)棧產(chǎn)品都有很大的變化和功能的擴(kuò)展。升級時官方資料顯示 ES 5.X 已經(jīng)比較穩(wěn)定，我們觀察一段時間后最后我們使用的版本是 5.5.0 版本，另外 5.X ES 優(yōu)化了 indexing 也是我們很期待的。ES 集群升級 采用官方提供的離線升級方式，直接用新版本軟件替換掉老版本并保證原數(shù)據(jù)可用。升級前使用 ES migration 遷移插件檢查升級前潛在的問題A. node 屬性新版本一些 node 屬性名稱發(fā)生了變化，如 node.

28、box_type 改成 node.attr.box_type。新版本沒有 client node 了，分為 master node，data node，ingest node，coordinating only node，設(shè)置方法分別是：B. index settingsES 從 5.0 開始 index 相關(guān)參數(shù)均不在 config 文件里配置，而需要在集群索引級別中進(jìn)行設(shè)置（除了 index.codec 等類似實(shí)例級別可以在 node 級別設(shè)置）。注意執(zhí)行下面這條語句會報錯，因?yàn)檫@幾個參數(shù)都是不能動態(tài)修改的。C. 重命名設(shè)置5.X 參數(shù)名稱變化較大，bootstrap.mlockall 改

29、為 bootstrap.memory_lock， discovery.zen.initial_ping_timeout 改為 discovery.zen.ping_timeout，默認(rèn)是 3s，新版本去掉了 discovery.zen.initial_ping_timeout 和 discovery.zen.ping.timeout 兩個設(shè)置。D. 參數(shù)變化discovery.zen.ping.multicast 參數(shù)已經(jīng)廢棄，在 5.X 里去掉了多播，用單播或者 cloud discovery 插件，action.disable_delete_all_indices 改成 action.de

30、structive_requires_name，需要用 cluster update API 修改：5.X 里沒有這個 path.work: 配置，ES 5.X 里 translog 的 flush 參數(shù)只有index.translog.flush_threshold_size。ES 升級步驟大致如下：暫停 Logstash Indexer 日志數(shù)據(jù)寫入關(guān)閉集群 shard allocation手動執(zhí)行 POST /_flush?wait_for_ongoing，等到操作結(jié)束再返回手動執(zhí)行 POST /_flush/synced關(guān)閉所有 ES 集群節(jié)點(diǎn)執(zhí)行新版本 Elasticsearch 軟

31、件替換啟動所有 ES 集群節(jié)點(diǎn)重新開啟集群 shard allocation等待 recovery 完成，集群 health status 變成 green重新開啟 Logstash Indexer 日志數(shù)據(jù)寫入ES 集群升級以后一些相關(guān)插件和工具也需要捆綁升級，head 插件需要升級到 5.X，原來的 kopf 可視化監(jiān)控插件不再可用，我們使用 cerebro 代替 kopf，cerebro 和老版本的 kopf 插件頁面幾乎一模一樣，功能上可以完全替代。同時我們計劃采用最新版本引入的 cross-cluster 來實(shí)現(xiàn)跨中心跨集群訪問功能。IK 兼容性 升級過程中當(dāng)然不可能是一帆風(fēng)順的，期

32、間遇到了很多問題，現(xiàn)分享一個比較有代表性的“坑”給大家分享。ES 新版本程序替換重啟后，狀態(tài)一直是 red，查看日志，有大量關(guān)于 ik 的報錯，找不到 ik 的分析器，如下所示：在升級之前，我們已從 Github 的 ik 項(xiàng)目上得知，在 5.0 之后，ik 被改名，截圖如下：但是對于已有的索引，某些字段的分析器指定的是 ik，例如上圖報錯中索引 l-Kibana-2017.08 是升級前建立的索引，_all 字段指定的分析器是 ik，而升級后更名為 ik_smart，因此報找不到 ik 分析器的錯誤。雖然關(guān)閉索引之后修改索引的 analyzer 也可以實(shí)現(xiàn)分詞器名稱的修改（在不關(guān)閉索引的情況

33、下直接修改分析器會報錯），但由于索引眾多，為了更快的實(shí)現(xiàn)兼容，我們修改 Elasticsearch-analysis-ik 源碼解決，使得最新版 ik 插件也能支持名為 ik 的分析器。(/medcl/Elasticsearch-analysis-ik/pull/411/commits/63326ca322ccb8c1bd3662ab7c0bfd38a86a53cb）存儲層各個組件升級以后效果明顯，最直觀的感受就是之前 master 節(jié)點(diǎn)隨著時間的推移 heap 內(nèi)存使用率持續(xù)增長的問題沒有了。實(shí)際上存儲層不僅僅是對 ELK 進(jìn)行了升級，還進(jìn)行了調(diào)整底層索引組織結(jié)構(gòu)，對冗余數(shù)據(jù)進(jìn)行清理，開發(fā)常

34、用工具腳本，小規(guī)模資源擴(kuò)容等等一系列工作，所以經(jīng)過測試和實(shí)際使用評估，升級后平臺更加穩(wěn)定，查詢更加高效。冷熱數(shù)據(jù)控制 同時針對日志量數(shù)據(jù)量激增的情況，新架構(gòu)引入了 SSD 來提升 ES 的讀寫性能。單臺 ES 存儲有 2 塊 SD 盤和若干 SATA 盤，所以每臺 ES server 都啟動了 3 個 ES 節(jié)點(diǎn)，2 個 hot 節(jié)點(diǎn)和 1 個 warm 節(jié)點(diǎn)。Indexer 中指配置了 hot 節(jié)點(diǎn)的端口，通過 ES 中的模板定義保證實(shí)時數(shù)據(jù)只寫入 hot 節(jié)點(diǎn)。通過 ES 官方推薦的 curator 工具定時將數(shù)據(jù)從 hot 節(jié)點(diǎn)搬遷到 cold 節(jié)點(diǎn)，SSD 數(shù)據(jù)保留周期為一周。cura

35、tor 的 action 配置文件如下：生命周期管理上天眼日志平臺實(shí)施日志數(shù)據(jù)定期導(dǎo)入到大數(shù)據(jù)平臺 hdfs 策略，日志數(shù)據(jù)保留一個月，一個月前的數(shù)據(jù)根據(jù)定時任務(wù)定期導(dǎo)入到大數(shù)據(jù)平臺中，ELK 中不再保存，大數(shù)據(jù)平臺的日志、指標(biāo)數(shù)據(jù)保存期限是一年。注意：數(shù)據(jù)冷熱分離過程中使用到的 curator 也必須使用最新的版本才可以使用，在集群升級完畢以后也需要重新安裝。展示層（Presentation） Kibana 升級 Kibana5 可視化方式更加靈活、豐富，提供了更加多的組件和監(jiān)控可視化視圖，更多的功能和更好的用戶體驗(yàn)對于平臺使用者有極大的吸引力。Kibana 升級比較簡單，但是由于默認(rèn)新版本

36、無分詞的 raw 字段已經(jīng)變成了 keyword 字段，所以 Kibana 的 indices 屬性需要刷新，同時之前建立的 visualize 也需要進(jìn)行字段屬性調(diào)整。新版本的 Kibana 確實(shí)增加了豐富的視圖和展現(xiàn)功能，頁面顯示也更加美觀。多租戶訪問控制和數(shù)據(jù)脫敏顯示 由于 X-pack security 模塊是收費(fèi)的，我們通過自主開發(fā)的方式使用 Kibana proxy（地址 /gnuhpc/Kibana-multitenant-proxy）實(shí)現(xiàn)了 Kibana 權(quán)限控制和數(shù)據(jù)顯示脫敏。目前權(quán)限控制到索引層，即一個用戶只可以訪問指定的 Index，如果訪問其他 Index 則在 Kibana 上無法顯示。同時由于銀行業(yè)的數(shù)據(jù)敏感，我們還提供了在