張 振,劉俊艷
(北京匯通金財信息科技有限公司,北京 100053)
基于微服務架構的日志監控系統的設計與實現
張 振,劉俊艷
(北京匯通金財信息科技有限公司,北京 100053)
由于軟件系統的規模日趨擴大和由此帶來的復雜性,會產生大量的日志信息,這些日志需要存儲以備查詢和分析,而傳統的關系數據庫對日志存儲、查詢、分析的能力有限,因此,需要考慮一種大容量復雜場景的日志解決方案。本文介紹了一種基于微服務化架構的日志系統,在日志的收集、處理、存儲、展示各個流程都使用微服務方式部署,支持動態擴容縮容、支持大規模日志的處理和存儲,滿足了復雜使用場景的日志需[1]。
微服務;日志系統
隨著科學技術的發展以及云計算、P2P 等技術的普及,全球數據量呈現爆炸式的增長,尤其是大數據時代的到來,通過互聯網,用戶制造了海量的數據日志信息。2017年1月22日中國互聯網絡信息中心發布的《第39次中國互聯網絡發展狀況統計報告》中指出:我國2016年全年共計新增網民4299萬人,增長率為 6.2%,其中手機網民規模達 6.95億,占比達 95.1%,增長率連續3年超過10%[2]。手機網民最常使用即時通信APP:2016年,網民在手機端最經常使用的 APP 應用前三位分別是微信、QQ、淘寶,無論是微信、QQ、微博等社交通信軟件還是淘寶、京東等電商軟件,各系統每天產生的海量日志信息都達到了指數級。而傳統的關系數據庫對日志存儲、查詢、分析的能力有限,已無法滿足呈爆炸性增長的海量數據日志需求,為解決信息存儲容量、數據安全、日志搜索分析等問題,基于微服務架構的日志監控系統應運而生,如今已得到廣泛應用。使用日志監控系統能夠提前對潛在的風險進行發掘,分析、判斷并形成定性或定量的描述,從而采取應對措施來降低風險。這對提高信息通信系統的安全性、穩定性及其服務能力具有重要的理論價值和實際意義。系統采用多任務分布式技術對海量日志進行分析挖掘,應用規則關聯、統計關聯等分析方法,可以建立科學的分析模型,使得對日志的分析深度與事件的識別準確度得到進一步的提升。
本文闡述了基于微服務架構的日志處理方案設計,并結合近幾年來微服務架構在日志監控系統的應用情況,對日志監控系統的概念、特點、體系架構進行研究,以提升日志管理規模和管理效率。
1.1 微服務介紹
微服務是構建分布式系統的架構風格,是指開發一個單個小型的但有業務功能的服務,每個服務都有自己的處理和輕量通訊機制,可以部署在單個或多個服務器上。微服務也指一種松耦合的、有一定的有界上下文的面向服務架構。也就是說,如果每個服務都要同時修改,那么它們就不是微服務,因為它們緊耦合在一起;如果你需要掌握一個服務太多的上下文場景使用條件,那么它就是一個有上下文邊界的服務,這個定義來自DDD領域驅動設計[4-5]。
相對于單體架構和SOA,它的主要特點是組件化、松耦合、自治、去中心化,體現在以下幾個方面[4-5]:
1. 一組小的服務
服務粒度要小,而每個服務是針對一個單一職責的業務能力的封裝,專注做好一件事情。
2. 獨立部署運行和擴展
每個服務能夠獨立被部署并運行在一個進程內。這種運行和部署方式能夠賦予系統靈活的代碼組織方式和發布節奏,使得快速交付和應對變化成為可能。
3. 獨立開發和演化
技術選型靈活,不受遺留系統技術約束。合適的業務問題選擇合適的技術可以獨立演化。服務與服務之間采取與語言無關的API進行集成。相對單體架構,微服務架構是更面向業務創新的一種架構模式。
4. 獨立團隊和自治
團隊對服務的整個生命周期負責,工作在獨立的上下文中,自己決策自己治理,而不需要統一的指揮中心。團隊和團隊之間通過松散的社區部落進行銜接。
1.2 ELK 介紹
ELK由Elasticsearch、Logstash和Kibana三部分組件組成;
ELK具有如下幾個特點:
(1)處理方式靈活:Elasticsearch是實時全文索引,不需要像storm那樣預先編程才能使用[3];
(2)集群線性擴展:不管是 Elasticsearch集群還是 Logstash 集群都是可以線性擴展的[3];
(3)前端操作炫麗:Kibana界面上,只需要點擊鼠標,就可以完成搜索、聚合功能,生成炫麗的儀表板[3];
(4)檢索性能高效:雖然每次查詢都是實時計算,但是優秀的設計和實現基本可以達到全天數據查詢的秒級響應[3];
(5)配置簡易上手:Elasticsearch 全部采用JSON接口,Logstash是Ruby DSL設計,都是目前業界最通用的配置語法設計[3];
在本日志系統中,將Elasticsearch、Logstash、Kibana開源套件作為日志系統架構組件,并且在此基礎上進行了一系列的封裝開發,使之適用于本日志系統的架構模式。
1.2.1 Elasticsearch
Elasticsearch是一個基于 Lucene的搜索服務器。它提供了一個分布式多用戶能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java開發的,并作為 Apache許可條款下的開放源碼發布,是當前流行的企業級搜索引擎。設計用于云計算中,能夠達到實時搜索,穩定,可靠,快速,安裝使用方便,零配置,支持集群(Cluster,見圖1)自動發現,索引自動分片、索引副本機制(見圖2),多數據源,自動搜索負載等特點[7-10]。

圖1 集群Fig.1 Cluster
(1)節點(Node)和集群(Cluster)
節點是集群中的一個Elasticearch實例。集群是一組擁有共同的 cluster name的節點。其中一個節點就是一個 ES進程,多個節點組成一個集群。一般每個節點都運行在不同的操作系統上,配置好集群相關參數后 ES會自動組成集群。集群內部通過 ES 的選主算法選出主節點,而集群外部則是可以通過任何節點進行操作,無主從節點之分,對外表現對等,去中心化,有利于客戶端編程。

圖2 分片、復制Fig.2 Fragmentation, replication
(2)索引Index
索引在 ES中索引有兩層含義,作為動詞,它指的是把一個文檔保存到ES中的過程,索引一個文檔后,我們就可以使用ES搜索到這個文檔;作為名詞,它是指保存文檔的地方,相當于關系數據庫中的database概念,一個集群中可以包含多個索引。
(3)分片shard
ES是一個分布式系統,它保存索引時會選擇適合的“主分片”(Primary Shard),把索引保存到其中(我們可以把分片理解為一塊物理存儲區域)。分片的分法是固定的,而且是安裝時候就必須要決定好的(默認是5),后面就不能改變了。
既然有主分片,那肯定是有“從”分片的,在 ES里稱之為“副本分片”(Replica Shard)。副本分片主要有兩個作用:高可用:某分片節點掛了的話可走其他副本分片節點,節點恢復后上面的分片數據可通過其他節點恢復負載均衡:ES會自動根據負載情況控制搜索路由,副本分片可以將負載均攤。
(4)RESTful支持
ES支持RESTful訪問,并且ES的HTTP接口不只是可以進行業務操作(索引/搜索),還可以進行一些配置等。
(5)document文檔
一個文檔就是一個保存在es中的JSON文本,可以把它理解為關系型數據庫表中的一行。每個文檔都是保存在索引中的,擁有一種類型和 id。一個文檔是一個 JSON對象(一些語言中的 hash /hashmap / associative array)包含了0或多個字段(鍵值對)。原始的 JSON文本在索引后將被保存在_source字段里,搜索完成后返回值中默認是包含該字段的。
(6)id
Id是用于標識文檔的,一個文檔的索引/類型/id必須是唯一的。文檔id是自動生成的(如果不指定)。
(7)field字段
一個文檔包含了若干字段,或稱之為鍵值對。字段的值可以是簡單(標量)值(例如字符串、整型、日期),也可以是嵌套結構,例如數組或對象。一個字段類似于關系型數據庫表中的一列。每個字段的映射都有一個字段類型(不要和文檔類型搞混了),它描述了這個字段可以保存的值類型,例如整型、字符串、對象。映射還可以讓我們定義一個字段的值如何進行分析。
(8)mapping映射
一個映射類似于關系型數據庫中的模式定義。每個索引都存在一個映射,它定義了該索引中的每一種類型,以及索引相關的配置。映射可以顯示定義,或者在文檔被索引時自動創建。
1.2.2 Logstash
Logstash使用 Jruby語言編寫,對于使用者來講,Logstash本身是基于命令行界面,面向任務處理的。Logstash的軟件架構是一種帶有“管道-過濾器”風格的插件式架構,作為一個開源軟件,Logstash遵循Apache 2.0進行開源,第三方社區為其貢獻了大量插件,它可以實現數據傳輸,格式處理,格式化輸出,還有強大的插件功能它可以對日志進行收集、分析,并將其存儲供以后使用。主要特點:幾乎可以訪問任何數據、可以和多種外部應用結合、支持彈性擴展[7-10]。
● 輸入階段:接受不同來源的數據流入,可以配置codec插件進行簡單的處理。
● 過濾階段:對流入數據進行過濾等操作,傳遞給 output,其中“輸入”與“輸出”是必須有的,“過濾”階段是可選的。
● 輸出階段:將數據傳遞到消息隊列,文件系統等進行進一步處理,在ELK的日志系統中,輸出到ElasticSearch索引中。

圖3 Logstash業務流程圖Fig.3 Logstash business flowchart

圖4 Logstash 構成圖Fig.4 Logstash constitute a figure
三個階段的處理任務是異步的,不存在跨階段任務執行與同一個線程中的情況。
logstash由三個主要部分組成(見圖4):
(1)Shipper-發送日志數據;
(2)Broker-收集數據,缺省內置 Redis;
(3)Indexer-數據寫入;
1.2.3 Kibana
Kibana是一款基于 Apache開源協議,使用JavaScript 語言編寫,為Elasticsearch提供分析和可視化的 Web平臺。通過 Kibana來查詢、瀏覽并且可以與存儲在 Elasticsearch索引中的數據交互。還可以很容易的以各種各樣的圖表,表格和地圖樣式來針對數據執行高級的數據分析以及可視化。Kibana使得我們可以很容易的了解海量數據。它非常簡單,基于瀏覽器的界面使得您可以快速的創建并且實時顯示修改的 Elasticsearch查詢的儀表盤,而且Kibana的配置非常簡單,在幾分鐘內就可以成功安裝Kibana并查詢Elasticsearch,不需要任何額外的基礎設施[7-10]。
2.1 requestID 生成及傳遞
各個應用統一配置請求攔截器,當攔截到 http請求時,攔截器首先生成RequestID,接著收集應用的調用信息及一些用戶信息并加密輸出到日志中。
RequestID的生成是為各個應用日志間形成調用鏈,每次請求都會生成唯一的RequestID,在日志量非常龐大的情況下,帶有 RequestID的日志在排查故障,查詢用戶每次請求所產生的日志非常方便、快捷。
2.2 日志采集
日志采集階段會為每個應用服務器上都部署一個日志采集模塊,這個日志采集模塊的作用就是采集各服務器上的應用日志,logstash shipper根據配置將各應用日志采集到 redis集群中,logstash shipper會為各個應用定義唯一type用來以后生成索引用。
2.3 日志緩存

圖5 日志系統架構圖Fig.5 Log system architecture diagrams

圖6 Re questId傳遞圖Fig.6 Re questId passing figure
redis作為日志轉儲組件可以有效提高系統可用性,使用集群或者主備結構代替單實例,可以有效提高組件的可用性。在 redis中,數據統一緩存在key為logstash(key可自定義)的名字中,采用list數據類型作為日志采集的一個緩存區隊列,list類型是按照插入順序排序的字符串鏈表,這意味著無論數據量多么巨大,頭尾插入或刪除數據的速度非常快,利用List的Push/Pop操作即實現了消息隊列。
2.4 日志處理
日志處理階段是logstash indexer端從redis中讀取日志數據,并進行一系列的過濾處理然后存儲到到ElasticSearch中。其處理過程中要進行數據格式的轉換,比如抽取日期然后轉換為預定義的格式、抽取日志級別、RequestId等字段,抽取message字段信息,過濾字段信息根據條件進行刪除或合并等。還有通過GeoIP獲取ip所在地,根據系統定制過濾條件,正則解析、Json解析等;從日志信息中抓取關鍵字,根據type生成ElasticSearch的索引,并將日志信息寫入到ElasticSearch的index中。
2.5 日志存儲
日志存儲在ElasticSearch中,并且ElasticSearch也是使用集群方式來進行部署,通過設置 elasticsearch.yml的cluster.name來定義集群名稱,并且多個elasticsearch集群名要完全一樣,然后設置 node.name來區別每個 elasticsearch。ElasticSearch集群節點分為兩種類型:node.master、node.data。[6][11][12]
node.master:當設置為 true時,當前節點就成為了集群的管理節點(即主節點),主要功能是維護元數據,管理集群各個節點的狀態[6,11-12]。
node.data:當設置為true時,當前節點就成了數據節點,主要負責數據的存儲、查詢和導入[6,11-12]。
2.6 日志展示
本日志系統的界面使用了kibana開源框架,為Elasticsearch提供分析和可視化的 Web平臺。它可以在 Elasticsearch的索引中查找,交互數據,并生成各種維度的表圖。展示出了日志的查詢結果、日志的數量變化趨勢圖、日志生成的各種圖表視圖、分析儀表盤等。
本日志系統與常規 elk部署的日志系統不同,設計中為各個應用統一配置了請求攔截器,用來生成唯一的 RequestID和收集請求信息等,通過RequestID能查詢出整個請求的調用鏈日志詳情,對于排查異常、快速定位非常方便快捷。并且在日志收集、緩沖、處理、存儲等各個階段均采用了分布式、微服務化的部署方式,使日志處理的全流程均可根據實際使用情況,進行動態彈縮,有效地利用了物理資源,并能夠應對大規模的日志情況,由于采用了基于 lucene的倒排索引方式的日志存儲,提高了查詢和統計效率,在實際項目中使用效果良好[1]。
[1] 參考網FX361.COM. 基于微服務架構的日志系統. http://www.handmsg.com/page/2017/0315/1185754.shtml.
[2] 杜振南, 朱崇軍. 分布式文件系統綜述[J]. 軟件工程與應用, 2017, 6(2): 21-27.
[3] 扣bubuki.com. ELK-實用日志分析系統. http://www.bubuko.com/infodetail-2025984.html.
[4] PetterLiu. 博客園. 微服務架構設計. http://www.cnblogs.com/wintersun/p/6219259.html.
[5] 紐曼(Sam Newman). 微服務設計. 軟件工程及軟件方法學,2016-04-01.
[6] 饒琛琳. ELK Stack權威指南. 2017.
[7] Saurabh Chhajed(蘇庫拉·塞哈特). Learning ELK Stack.2016.
[8] 徐剛. IBMdeveloperWords. 集中式日志系統ELK協議棧詳解. https://www.ibm.com/developerworks/cn/opensource/oscn-elk/.
[9] CSDN博客. 漫談ELK在大數據運維中的應用. http://www.cnblogs.com/wintersun/p/6219259.html.
[10] 鄭彥生. 51CTO博客. ELK日志分析系統. http://467754239.blog.51cto.com/4878013/1700828/.
[11] elastic. 官網. https://www.elastic.co/guide/index.html.
[12] 饒琛琳. GitBook. ELKstack 中文指南. https://www.gitbook.com/book/chenryn/elk-stack-guide-cn/details.
Design and Implementation of Log Monitoring System Based on Microservice Architecture
ZHANG Zhen, LIU Jun-yan
(Beijing huitong jincai information technology Co., Ltd., Beijing 100053, China)
Due to the size of the software system and widening of the complexity of the resulting will produce large amounts of log information, these logs need to be stored for query and analysis, and the traditional relational database log storage, query, analysis ability is limited, therefore, need to consider a large log solution of complex scenes.In this paper, a logging system based on micro structure of service, in log collection, processing, storage and display each process using micro service deployment, support for dynamic expansion shrinkage mass log processing and storage capacity, support, to satisfy the complex usage scenarios of log.
Micro-service; Log system
TP311
A
10.3969/j.issn.1003-6970.2017.11.037
本文著錄格式:張振,劉俊艷. 基于微服務架構的日志監控系統的設計與實現[J]. 軟件,2017,38(11):196-201
張振(1986-),男,本科,北京匯通金財信息科技有限公司,主要研究方向:互聯網技術;劉俊艷(1978-),女,碩士,北京匯通金財信息科技有限公司,主要研究方向:計算機應用。