張 振,劉俊艷
(北京匯通金財(cái)信息科技有限公司,北京 100053)
基于微服務(wù)架構(gòu)的日志監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)
張 振,劉俊艷
(北京匯通金財(cái)信息科技有限公司,北京 100053)
由于軟件系統(tǒng)的規(guī)模日趨擴(kuò)大和由此帶來(lái)的復(fù)雜性,會(huì)產(chǎn)生大量的日志信息,這些日志需要存儲(chǔ)以備查詢(xún)和分析,而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)對(duì)日志存儲(chǔ)、查詢(xún)、分析的能力有限,因此,需要考慮一種大容量復(fù)雜場(chǎng)景的日志解決方案。本文介紹了一種基于微服務(wù)化架構(gòu)的日志系統(tǒng),在日志的收集、處理、存儲(chǔ)、展示各個(gè)流程都使用微服務(wù)方式部署,支持動(dòng)態(tài)擴(kuò)容縮容、支持大規(guī)模日志的處理和存儲(chǔ),滿(mǎn)足了復(fù)雜使用場(chǎng)景的日志需[1]。
微服務(wù);日志系統(tǒng)
隨著科學(xué)技術(shù)的發(fā)展以及云計(jì)算、P2P 等技術(shù)的普及,全球數(shù)據(jù)量呈現(xiàn)爆炸式的增長(zhǎng),尤其是大數(shù)據(jù)時(shí)代的到來(lái),通過(guò)互聯(lián)網(wǎng),用戶(hù)制造了海量的數(shù)據(jù)日志信息。2017年1月22日中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心發(fā)布的《第39次中國(guó)互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告》中指出:我國(guó)2016年全年共計(jì)新增網(wǎng)民4299萬(wàn)人,增長(zhǎng)率為 6.2%,其中手機(jī)網(wǎng)民規(guī)模達(dá) 6.95億,占比達(dá) 95.1%,增長(zhǎng)率連續(xù)3年超過(guò)10%[2]。手機(jī)網(wǎng)民最常使用即時(shí)通信APP:2016年,網(wǎng)民在手機(jī)端最經(jīng)常使用的 APP 應(yīng)用前三位分別是微信、QQ、淘寶,無(wú)論是微信、QQ、微博等社交通信軟件還是淘寶、京東等電商軟件,各系統(tǒng)每天產(chǎn)生的海量日志信息都達(dá)到了指數(shù)級(jí)。而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)對(duì)日志存儲(chǔ)、查詢(xún)、分析的能力有限,已無(wú)法滿(mǎn)足呈爆炸性增長(zhǎng)的海量數(shù)據(jù)日志需求,為解決信息存儲(chǔ)容量、數(shù)據(jù)安全、日志搜索分析等問(wèn)題,基于微服務(wù)架構(gòu)的日志監(jiān)控系統(tǒng)應(yīng)運(yùn)而生,如今已得到廣泛應(yīng)用。使用日志監(jiān)控系統(tǒng)能夠提前對(duì)潛在的風(fēng)險(xiǎn)進(jìn)行發(fā)掘,分析、判斷并形成定性或定量的描述,從而采取應(yīng)對(duì)措施來(lái)降低風(fēng)險(xiǎn)。這對(duì)提高信息通信系統(tǒng)的安全性、穩(wěn)定性及其服務(wù)能力具有重要的理論價(jià)值和實(shí)際意義。系統(tǒng)采用多任務(wù)分布式技術(shù)對(duì)海量日志進(jìn)行分析挖掘,應(yīng)用規(guī)則關(guān)聯(lián)、統(tǒng)計(jì)關(guān)聯(lián)等分析方法,可以建立科學(xué)的分析模型,使得對(duì)日志的分析深度與事件的識(shí)別準(zhǔn)確度得到進(jìn)一步的提升。
本文闡述了基于微服務(wù)架構(gòu)的日志處理方案設(shè)計(jì),并結(jié)合近幾年來(lái)微服務(wù)架構(gòu)在日志監(jiān)控系統(tǒng)的應(yīng)用情況,對(duì)日志監(jiān)控系統(tǒng)的概念、特點(diǎn)、體系架構(gòu)進(jìn)行研究,以提升日志管理規(guī)模和管理效率。
1.1 微服務(wù)介紹
微服務(wù)是構(gòu)建分布式系統(tǒng)的架構(gòu)風(fēng)格,是指開(kāi)發(fā)一個(gè)單個(gè)小型的但有業(yè)務(wù)功能的服務(wù),每個(gè)服務(wù)都有自己的處理和輕量通訊機(jī)制,可以部署在單個(gè)或多個(gè)服務(wù)器上。微服務(wù)也指一種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說(shuō),如果每個(gè)服務(wù)都要同時(shí)修改,那么它們就不是微服務(wù),因?yàn)樗鼈兙o耦合在一起;如果你需要掌握一個(gè)服務(wù)太多的上下文場(chǎng)景使用條件,那么它就是一個(gè)有上下文邊界的服務(wù),這個(gè)定義來(lái)自DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)[4-5]。
相對(duì)于單體架構(gòu)和SOA,它的主要特點(diǎn)是組件化、松耦合、自治、去中心化,體現(xiàn)在以下幾個(gè)方面[4-5]:
1. 一組小的服務(wù)
服務(wù)粒度要小,而每個(gè)服務(wù)是針對(duì)一個(gè)單一職責(zé)的業(yè)務(wù)能力的封裝,專(zhuān)注做好一件事情。
2. 獨(dú)立部署運(yùn)行和擴(kuò)展
每個(gè)服務(wù)能夠獨(dú)立被部署并運(yùn)行在一個(gè)進(jìn)程內(nèi)。這種運(yùn)行和部署方式能夠賦予系統(tǒng)靈活的代碼組織方式和發(fā)布節(jié)奏,使得快速交付和應(yīng)對(duì)變化成為可能。
3. 獨(dú)立開(kāi)發(fā)和演化
技術(shù)選型靈活,不受遺留系統(tǒng)技術(shù)約束。合適的業(yè)務(wù)問(wèn)題選擇合適的技術(shù)可以獨(dú)立演化。服務(wù)與服務(wù)之間采取與語(yǔ)言無(wú)關(guān)的API進(jìn)行集成。相對(duì)單體架構(gòu),微服務(wù)架構(gòu)是更面向業(yè)務(wù)創(chuàng)新的一種架構(gòu)模式。
4. 獨(dú)立團(tuán)隊(duì)和自治
團(tuán)隊(duì)對(duì)服務(wù)的整個(gè)生命周期負(fù)責(zé),工作在獨(dú)立的上下文中,自己決策自己治理,而不需要統(tǒng)一的指揮中心。團(tuán)隊(duì)和團(tuán)隊(duì)之間通過(guò)松散的社區(qū)部落進(jìn)行銜接。
1.2 ELK 介紹
ELK由Elasticsearch、Logstash和Kibana三部分組件組成;
ELK具有如下幾個(gè)特點(diǎn):
(1)處理方式靈活:Elasticsearch是實(shí)時(shí)全文索引,不需要像storm那樣預(yù)先編程才能使用[3];
(2)集群線(xiàn)性擴(kuò)展:不管是 Elasticsearch集群還是 Logstash 集群都是可以線(xiàn)性擴(kuò)展的[3];
(3)前端操作炫麗:Kibana界面上,只需要點(diǎn)擊鼠標(biāo),就可以完成搜索、聚合功能,生成炫麗的儀表板[3];
(4)檢索性能高效:雖然每次查詢(xún)都是實(shí)時(shí)計(jì)算,但是優(yōu)秀的設(shè)計(jì)和實(shí)現(xiàn)基本可以達(dá)到全天數(shù)據(jù)查詢(xún)的秒級(jí)響應(yīng)[3];
(5)配置簡(jiǎn)易上手:Elasticsearch 全部采用JSON接口,Logstash是Ruby DSL設(shè)計(jì),都是目前業(yè)界最通用的配置語(yǔ)法設(shè)計(jì)[3];
在本日志系統(tǒng)中,將Elasticsearch、Logstash、Kibana開(kāi)源套件作為日志系統(tǒng)架構(gòu)組件,并且在此基礎(chǔ)上進(jìn)行了一系列的封裝開(kāi)發(fā),使之適用于本日志系統(tǒng)的架構(gòu)模式。
1.2.1 Elasticsearch
Elasticsearch是一個(gè)基于 Lucene的搜索服務(wù)器。它提供了一個(gè)分布式多用戶(hù)能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java開(kāi)發(fā)的,并作為 Apache許可條款下的開(kāi)放源碼發(fā)布,是當(dāng)前流行的企業(yè)級(jí)搜索引擎。設(shè)計(jì)用于云計(jì)算中,能夠達(dá)到實(shí)時(shí)搜索,穩(wěn)定,可靠,快速,安裝使用方便,零配置,支持集群(Cluster,見(jiàn)圖1)自動(dòng)發(fā)現(xiàn),索引自動(dòng)分片、索引副本機(jī)制(見(jiàn)圖2),多數(shù)據(jù)源,自動(dòng)搜索負(fù)載等特點(diǎn)[7-10]。
圖1 集群Fig.1 Cluster
(1)節(jié)點(diǎn)(Node)和集群(Cluster)
節(jié)點(diǎn)是集群中的一個(gè)Elasticearch實(shí)例。集群是一組擁有共同的 cluster name的節(jié)點(diǎn)。其中一個(gè)節(jié)點(diǎn)就是一個(gè) ES進(jìn)程,多個(gè)節(jié)點(diǎn)組成一個(gè)集群。一般每個(gè)節(jié)點(diǎn)都運(yùn)行在不同的操作系統(tǒng)上,配置好集群相關(guān)參數(shù)后 ES會(huì)自動(dòng)組成集群。集群內(nèi)部通過(guò) ES 的選主算法選出主節(jié)點(diǎn),而集群外部則是可以通過(guò)任何節(jié)點(diǎn)進(jìn)行操作,無(wú)主從節(jié)點(diǎn)之分,對(duì)外表現(xiàn)對(duì)等,去中心化,有利于客戶(hù)端編程。
圖2 分片、復(fù)制Fig.2 Fragmentation, replication
(2)索引Index
索引在 ES中索引有兩層含義,作為動(dòng)詞,它指的是把一個(gè)文檔保存到ES中的過(guò)程,索引一個(gè)文檔后,我們就可以使用ES搜索到這個(gè)文檔;作為名詞,它是指保存文檔的地方,相當(dāng)于關(guān)系數(shù)據(jù)庫(kù)中的database概念,一個(gè)集群中可以包含多個(gè)索引。
(3)分片shard
ES是一個(gè)分布式系統(tǒng),它保存索引時(shí)會(huì)選擇適合的“主分片”(Primary Shard),把索引保存到其中(我們可以把分片理解為一塊物理存儲(chǔ)區(qū)域)。分片的分法是固定的,而且是安裝時(shí)候就必須要決定好的(默認(rèn)是5),后面就不能改變了。
既然有主分片,那肯定是有“從”分片的,在 ES里稱(chēng)之為“副本分片”(Replica Shard)。副本分片主要有兩個(gè)作用:高可用:某分片節(jié)點(diǎn)掛了的話(huà)可走其他副本分片節(jié)點(diǎn),節(jié)點(diǎn)恢復(fù)后上面的分片數(shù)據(jù)可通過(guò)其他節(jié)點(diǎn)恢復(fù)負(fù)載均衡:ES會(huì)自動(dòng)根據(jù)負(fù)載情況控制搜索路由,副本分片可以將負(fù)載均攤。
(4)RESTful支持
ES支持RESTful訪(fǎng)問(wèn),并且ES的HTTP接口不只是可以進(jìn)行業(yè)務(wù)操作(索引/搜索),還可以進(jìn)行一些配置等。
(5)document文檔
一個(gè)文檔就是一個(gè)保存在es中的JSON文本,可以把它理解為關(guān)系型數(shù)據(jù)庫(kù)表中的一行。每個(gè)文檔都是保存在索引中的,擁有一種類(lèi)型和 id。一個(gè)文檔是一個(gè) JSON對(duì)象(一些語(yǔ)言中的 hash /hashmap / associative array)包含了0或多個(gè)字段(鍵值對(duì))。原始的 JSON文本在索引后將被保存在_source字段里,搜索完成后返回值中默認(rèn)是包含該字段的。
(6)id
Id是用于標(biāo)識(shí)文檔的,一個(gè)文檔的索引/類(lèi)型/id必須是唯一的。文檔id是自動(dòng)生成的(如果不指定)。
(7)field字段
一個(gè)文檔包含了若干字段,或稱(chēng)之為鍵值對(duì)。字段的值可以是簡(jiǎn)單(標(biāo)量)值(例如字符串、整型、日期),也可以是嵌套結(jié)構(gòu),例如數(shù)組或?qū)ο?。一個(gè)字段類(lèi)似于關(guān)系型數(shù)據(jù)庫(kù)表中的一列。每個(gè)字段的映射都有一個(gè)字段類(lèi)型(不要和文檔類(lèi)型搞混了),它描述了這個(gè)字段可以保存的值類(lèi)型,例如整型、字符串、對(duì)象。映射還可以讓我們定義一個(gè)字段的值如何進(jìn)行分析。
(8)mapping映射
一個(gè)映射類(lèi)似于關(guān)系型數(shù)據(jù)庫(kù)中的模式定義。每個(gè)索引都存在一個(gè)映射,它定義了該索引中的每一種類(lèi)型,以及索引相關(guān)的配置。映射可以顯示定義,或者在文檔被索引時(shí)自動(dòng)創(chuàng)建。
1.2.2 Logstash
Logstash使用 Jruby語(yǔ)言編寫(xiě),對(duì)于使用者來(lái)講,Logstash本身是基于命令行界面,面向任務(wù)處理的。Logstash的軟件架構(gòu)是一種帶有“管道-過(guò)濾器”風(fēng)格的插件式架構(gòu),作為一個(gè)開(kāi)源軟件,Logstash遵循Apache 2.0進(jìn)行開(kāi)源,第三方社區(qū)為其貢獻(xiàn)了大量插件,它可以實(shí)現(xiàn)數(shù)據(jù)傳輸,格式處理,格式化輸出,還有強(qiáng)大的插件功能它可以對(duì)日志進(jìn)行收集、分析,并將其存儲(chǔ)供以后使用。主要特點(diǎn):幾乎可以訪(fǎng)問(wèn)任何數(shù)據(jù)、可以和多種外部應(yīng)用結(jié)合、支持彈性擴(kuò)展[7-10]。
● 輸入階段:接受不同來(lái)源的數(shù)據(jù)流入,可以配置codec插件進(jìn)行簡(jiǎn)單的處理。
● 過(guò)濾階段:對(duì)流入數(shù)據(jù)進(jìn)行過(guò)濾等操作,傳遞給 output,其中“輸入”與“輸出”是必須有的,“過(guò)濾”階段是可選的。
● 輸出階段:將數(shù)據(jù)傳遞到消息隊(duì)列,文件系統(tǒng)等進(jìn)行進(jìn)一步處理,在ELK的日志系統(tǒng)中,輸出到ElasticSearch索引中。
圖3 Logstash業(yè)務(wù)流程圖Fig.3 Logstash business flowchart
圖4 Logstash 構(gòu)成圖Fig.4 Logstash constitute a figure
三個(gè)階段的處理任務(wù)是異步的,不存在跨階段任務(wù)執(zhí)行與同一個(gè)線(xiàn)程中的情況。
logstash由三個(gè)主要部分組成(見(jiàn)圖4):
(1)Shipper-發(fā)送日志數(shù)據(jù);
(2)Broker-收集數(shù)據(jù),缺省內(nèi)置 Redis;
(3)Indexer-數(shù)據(jù)寫(xiě)入;
1.2.3 Kibana
Kibana是一款基于 Apache開(kāi)源協(xié)議,使用JavaScript 語(yǔ)言編寫(xiě),為Elasticsearch提供分析和可視化的 Web平臺(tái)。通過(guò) Kibana來(lái)查詢(xún)、瀏覽并且可以與存儲(chǔ)在 Elasticsearch索引中的數(shù)據(jù)交互。還可以很容易的以各種各樣的圖表,表格和地圖樣式來(lái)針對(duì)數(shù)據(jù)執(zhí)行高級(jí)的數(shù)據(jù)分析以及可視化。Kibana使得我們可以很容易的了解海量數(shù)據(jù)。它非常簡(jiǎn)單,基于瀏覽器的界面使得您可以快速的創(chuàng)建并且實(shí)時(shí)顯示修改的 Elasticsearch查詢(xún)的儀表盤(pán),而且Kibana的配置非常簡(jiǎn)單,在幾分鐘內(nèi)就可以成功安裝Kibana并查詢(xún)Elasticsearch,不需要任何額外的基礎(chǔ)設(shè)施[7-10]。
2.1 requestID 生成及傳遞
各個(gè)應(yīng)用統(tǒng)一配置請(qǐng)求攔截器,當(dāng)攔截到 http請(qǐng)求時(shí),攔截器首先生成RequestID,接著收集應(yīng)用的調(diào)用信息及一些用戶(hù)信息并加密輸出到日志中。
RequestID的生成是為各個(gè)應(yīng)用日志間形成調(diào)用鏈,每次請(qǐng)求都會(huì)生成唯一的RequestID,在日志量非常龐大的情況下,帶有 RequestID的日志在排查故障,查詢(xún)用戶(hù)每次請(qǐng)求所產(chǎn)生的日志非常方便、快捷。
2.2 日志采集
日志采集階段會(huì)為每個(gè)應(yīng)用服務(wù)器上都部署一個(gè)日志采集模塊,這個(gè)日志采集模塊的作用就是采集各服務(wù)器上的應(yīng)用日志,logstash shipper根據(jù)配置將各應(yīng)用日志采集到 redis集群中,logstash shipper會(huì)為各個(gè)應(yīng)用定義唯一type用來(lái)以后生成索引用。
2.3 日志緩存
圖5 日志系統(tǒng)架構(gòu)圖Fig.5 Log system architecture diagrams
圖6 Re questId傳遞圖Fig.6 Re questId passing figure
redis作為日志轉(zhuǎn)儲(chǔ)組件可以有效提高系統(tǒng)可用性,使用集群或者主備結(jié)構(gòu)代替單實(shí)例,可以有效提高組件的可用性。在 redis中,數(shù)據(jù)統(tǒng)一緩存在key為logstash(key可自定義)的名字中,采用list數(shù)據(jù)類(lèi)型作為日志采集的一個(gè)緩存區(qū)隊(duì)列,list類(lèi)型是按照插入順序排序的字符串鏈表,這意味著無(wú)論數(shù)據(jù)量多么巨大,頭尾插入或刪除數(shù)據(jù)的速度非??欤肔ist的Push/Pop操作即實(shí)現(xiàn)了消息隊(duì)列。
2.4 日志處理
日志處理階段是logstash indexer端從redis中讀取日志數(shù)據(jù),并進(jìn)行一系列的過(guò)濾處理然后存儲(chǔ)到到ElasticSearch中。其處理過(guò)程中要進(jìn)行數(shù)據(jù)格式的轉(zhuǎn)換,比如抽取日期然后轉(zhuǎn)換為預(yù)定義的格式、抽取日志級(jí)別、RequestId等字段,抽取message字段信息,過(guò)濾字段信息根據(jù)條件進(jìn)行刪除或合并等。還有通過(guò)GeoIP獲取ip所在地,根據(jù)系統(tǒng)定制過(guò)濾條件,正則解析、Json解析等;從日志信息中抓取關(guān)鍵字,根據(jù)type生成ElasticSearch的索引,并將日志信息寫(xiě)入到ElasticSearch的index中。
2.5 日志存儲(chǔ)
日志存儲(chǔ)在ElasticSearch中,并且ElasticSearch也是使用集群方式來(lái)進(jìn)行部署,通過(guò)設(shè)置 elasticsearch.yml的cluster.name來(lái)定義集群名稱(chēng),并且多個(gè)elasticsearch集群名要完全一樣,然后設(shè)置 node.name來(lái)區(qū)別每個(gè) elasticsearch。ElasticSearch集群節(jié)點(diǎn)分為兩種類(lèi)型:node.master、node.data。[6][11][12]
node.master:當(dāng)設(shè)置為 true時(shí),當(dāng)前節(jié)點(diǎn)就成為了集群的管理節(jié)點(diǎn)(即主節(jié)點(diǎn)),主要功能是維護(hù)元數(shù)據(jù),管理集群各個(gè)節(jié)點(diǎn)的狀態(tài)[6,11-12]。
node.data:當(dāng)設(shè)置為true時(shí),當(dāng)前節(jié)點(diǎn)就成了數(shù)據(jù)節(jié)點(diǎn),主要負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)、查詢(xún)和導(dǎo)入[6,11-12]。
2.6 日志展示
本日志系統(tǒng)的界面使用了kibana開(kāi)源框架,為Elasticsearch提供分析和可視化的 Web平臺(tái)。它可以在 Elasticsearch的索引中查找,交互數(shù)據(jù),并生成各種維度的表圖。展示出了日志的查詢(xún)結(jié)果、日志的數(shù)量變化趨勢(shì)圖、日志生成的各種圖表視圖、分析儀表盤(pán)等。
本日志系統(tǒng)與常規(guī) elk部署的日志系統(tǒng)不同,設(shè)計(jì)中為各個(gè)應(yīng)用統(tǒng)一配置了請(qǐng)求攔截器,用來(lái)生成唯一的 RequestID和收集請(qǐng)求信息等,通過(guò)RequestID能查詢(xún)出整個(gè)請(qǐng)求的調(diào)用鏈日志詳情,對(duì)于排查異常、快速定位非常方便快捷。并且在日志收集、緩沖、處理、存儲(chǔ)等各個(gè)階段均采用了分布式、微服務(wù)化的部署方式,使日志處理的全流程均可根據(jù)實(shí)際使用情況,進(jìn)行動(dòng)態(tài)彈縮,有效地利用了物理資源,并能夠應(yīng)對(duì)大規(guī)模的日志情況,由于采用了基于 lucene的倒排索引方式的日志存儲(chǔ),提高了查詢(xún)和統(tǒng)計(jì)效率,在實(shí)際項(xiàng)目中使用效果良好[1]。
[1] 參考網(wǎng)FX361.COM. 基于微服務(wù)架構(gòu)的日志系統(tǒng). http://www.jizihe.com/page/2017/0315/1185754.shtml.
[2] 杜振南, 朱崇軍. 分布式文件系統(tǒng)綜述[J]. 軟件工程與應(yīng)用, 2017, 6(2): 21-27.
[3] 扣bubuki.com. ELK-實(shí)用日志分析系統(tǒng). http://www.bubuko.com/infodetail-2025984.html.
[4] PetterLiu. 博客園. 微服務(wù)架構(gòu)設(shè)計(jì). http://www.cnblogs.com/wintersun/p/6219259.html.
[5] 紐曼(Sam Newman). 微服務(wù)設(shè)計(jì). 軟件工程及軟件方法學(xué),2016-04-01.
[6] 饒琛琳. ELK Stack權(quán)威指南. 2017.
[7] Saurabh Chhajed(蘇庫(kù)拉·塞哈特). Learning ELK Stack.2016.
[8] 徐剛. IBMdeveloperWords. 集中式日志系統(tǒng)ELK協(xié)議棧詳解. https://www.ibm.com/developerworks/cn/opensource/oscn-elk/.
[9] CSDN博客. 漫談ELK在大數(shù)據(jù)運(yùn)維中的應(yīng)用. http://www.cnblogs.com/wintersun/p/6219259.html.
[10] 鄭彥生. 51CTO博客. ELK日志分析系統(tǒng). http://467754239.blog.51cto.com/4878013/1700828/.
[11] elastic. 官網(wǎng). 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
本文著錄格式:張振,劉俊艷. 基于微服務(wù)架構(gòu)的日志監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件,2017,38(11):196-201
張振(1986-),男,本科,北京匯通金財(cái)信息科技有限公司,主要研究方向:互聯(lián)網(wǎng)技術(shù);劉俊艷(1978-),女,碩士,北京匯通金財(cái)信息科技有限公司,主要研究方向:計(jì)算機(jī)應(yīng)用。