王力群 黃必棟

(南京鐵道職業(yè)技術(shù)學(xué)院軟件技術(shù)系 江蘇 南京 210031)

基于日志分析平臺(tái)的監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

王力群 黃必棟

(南京鐵道職業(yè)技術(shù)學(xué)院軟件技術(shù)系 江蘇 南京 210031)

介紹基于日志分析平臺(tái)的監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)。針對(duì)復(fù)雜軟件系統(tǒng)的監(jiān)控點(diǎn)類型多樣、監(jiān)控點(diǎn)數(shù)量多、監(jiān)控點(diǎn)易變化、監(jiān)控?cái)?shù)據(jù)量大等問題，提出一種基于日志分析平臺(tái)ELK的監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)方法。通過對(duì)日志分析平臺(tái)ELK進(jìn)行改造，把日志處理中的收集、存儲(chǔ)、索引、搜索、分析方法引入到監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)中，解決了傳統(tǒng)監(jiān)控方法存在的問題，為監(jiān)控系統(tǒng)的設(shè)計(jì)提出了新的思路。

監(jiān)控系統(tǒng) 日志分析 ELK Elasticsearch

0 引 言

穩(wěn)定、可靠、高性能的軟件系統(tǒng)是以用戶大量使用及反饋為基礎(chǔ)，不斷滿足新需求，不斷完善和改進(jìn)系統(tǒng)功能與性能，不斷演化系統(tǒng)架構(gòu)與技術(shù)而形成。如互聯(lián)網(wǎng)系統(tǒng)，大量用戶的高并發(fā)訪問和使用，能及時(shí)反饋并發(fā)現(xiàn)問題，從而使系統(tǒng)不斷地進(jìn)行調(diào)整、完善以滿足新的改進(jìn)需求。而監(jiān)控系統(tǒng)在發(fā)現(xiàn)問題、提高系統(tǒng)穩(wěn)定性、分析系統(tǒng)性能等方面發(fā)揮著巨大的作用[1-2]。

監(jiān)控系統(tǒng)能實(shí)時(shí)收集系統(tǒng)運(yùn)行指標(biāo)，通過配置好的監(jiān)控規(guī)則及時(shí)發(fā)現(xiàn)系統(tǒng)異常，并通過有效途徑進(jìn)行報(bào)警和通知。系統(tǒng)運(yùn)行指標(biāo)可分為系統(tǒng)底層運(yùn)行指標(biāo)和業(yè)務(wù)運(yùn)行數(shù)據(jù)指標(biāo)，通用的監(jiān)控系統(tǒng)軟件一般監(jiān)控系統(tǒng)底層運(yùn)行指標(biāo)，如開源監(jiān)控系統(tǒng)Zabbix可以監(jiān)控系統(tǒng)底層異常，包括進(jìn)程異常、IO異常、內(nèi)存異常、網(wǎng)絡(luò)異常等[3]。而由于業(yè)務(wù)系統(tǒng)架構(gòu)的多樣化、不同業(yè)務(wù)系統(tǒng)間的差異大等特征，業(yè)務(wù)運(yùn)行指標(biāo)的監(jiān)控沒有通用的軟件系統(tǒng)可以使用，通常業(yè)務(wù)監(jiān)控系統(tǒng)需要進(jìn)行定制化的搭建。業(yè)務(wù)運(yùn)行指標(biāo)數(shù)據(jù)一般通過BI系統(tǒng)、業(yè)務(wù)日志保存，通過BI系統(tǒng)可以分析歷史業(yè)務(wù)數(shù)據(jù)，但不具備實(shí)時(shí)性；而業(yè)務(wù)日志的分析則通過日志分析軟件，分析緩慢且依賴于開發(fā)人員的經(jīng)驗(yàn)，發(fā)現(xiàn)問題比較滯后。能否把業(yè)務(wù)指標(biāo)數(shù)據(jù)統(tǒng)一收集、存儲(chǔ)，并可以方便檢索、分析、統(tǒng)計(jì)是解決系統(tǒng)監(jiān)控問題的關(guān)鍵。

本文介紹了一種基于日志分析平臺(tái)ELK的監(jiān)控系統(tǒng)設(shè)計(jì)。日志分析平臺(tái)ELK是近年來迅速發(fā)展的開源日志分析平臺(tái)，包含了Elasticsearch全文檢索數(shù)據(jù)庫、Logstash日志收集器和Kibana可視化數(shù)據(jù)搜索、統(tǒng)計(jì)Web接口。監(jiān)控系統(tǒng)以Logstash日志收集器為基礎(chǔ)擴(kuò)展了業(yè)務(wù)數(shù)據(jù)收集方法，使用Elasticsearch存儲(chǔ)、索引業(yè)務(wù)運(yùn)行數(shù)據(jù)，基于Elasticsearch API構(gòu)建了監(jiān)控模塊。解決了業(yè)務(wù)數(shù)據(jù)的收集難，存儲(chǔ)和分析困難的問題，提出了易擴(kuò)展、可靈活配置和可快速搭建的監(jiān)控系統(tǒng)框架。

1 架構(gòu)設(shè)計(jì)

1.1 體系結(jié)構(gòu)

監(jiān)控系統(tǒng)的設(shè)計(jì)以ELK日志分析平臺(tái)為基礎(chǔ)，采用了Kafka消息隊(duì)列作為數(shù)據(jù)傳送緩沖器，實(shí)現(xiàn)了數(shù)據(jù)收集API、監(jiān)控服務(wù)、監(jiān)控Web接口，系統(tǒng)架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)

在業(yè)務(wù)運(yùn)行服務(wù)器中通過兩種方法采集數(shù)據(jù)：(1) 通過Logstash收集文件更新數(shù)據(jù)；(2) 通過數(shù)據(jù)收集API收集業(yè)務(wù)程序中的數(shù)據(jù)。收集到的數(shù)據(jù)統(tǒng)一發(fā)送到數(shù)據(jù)傳送緩沖器Kafka，再通過Logstash傳送到Elasticsearch數(shù)據(jù)庫。Elasticsearch API是一種基于HTTP協(xié)議的RESTful API，其提供了數(shù)據(jù)搜索、統(tǒng)計(jì)等功能，這方便了基于Elasticsearch進(jìn)行二次開發(fā)[4]。監(jiān)控服務(wù)根據(jù)配置好的監(jiān)控指標(biāo)規(guī)則，使用Elasticsearch API周期性的查詢、計(jì)算監(jiān)控指標(biāo)。用戶通過監(jiān)控Web接口對(duì)監(jiān)控任務(wù)進(jìn)行配置，并可以查詢歷史監(jiān)控記錄，方便了對(duì)監(jiān)控事件的跟蹤和查詢。ELK中的Kibana提供了靈活、易用的Web接口，使用戶能搜索、統(tǒng)計(jì)收集到的監(jiān)控?cái)?shù)據(jù)，并可對(duì)監(jiān)控規(guī)則進(jìn)行驗(yàn)證。

1.2 數(shù)據(jù)收集

數(shù)據(jù)收集是指把運(yùn)行中的程序數(shù)據(jù)通過某種方法收集起來，這些數(shù)據(jù)包括了用戶訪問設(shè)定的參數(shù)、用戶訪問接口數(shù)據(jù)、內(nèi)部服務(wù)接口調(diào)用數(shù)據(jù)、外部接口調(diào)用數(shù)據(jù)、開發(fā)人員自定義的業(yè)務(wù)指標(biāo)等。其中的接口調(diào)用數(shù)據(jù)還包含請(qǐng)求、返回、調(diào)用時(shí)間、調(diào)用異常信息等。數(shù)據(jù)收集點(diǎn)示例如圖2所示，實(shí)心圓點(diǎn)代表的是數(shù)據(jù)收集點(diǎn)。收集點(diǎn)分布在前端(Web頁面和App)與后臺(tái)交互處、前端服務(wù)接口處(如PHP層接口)、后臺(tái)業(yè)務(wù)服務(wù)調(diào)用點(diǎn)、第三方服務(wù)調(diào)用點(diǎn)等關(guān)鍵點(diǎn)中。這樣用戶訪問行為數(shù)據(jù)、內(nèi)部服務(wù)交互數(shù)據(jù)、數(shù)據(jù)訪問交互行為、第三方服務(wù)訪問數(shù)據(jù)都可以被收集到。數(shù)據(jù)收集方法及與業(yè)務(wù)程序的集成方法是數(shù)據(jù)收集的關(guān)鍵。

圖2 數(shù)據(jù)收集

根據(jù)收集的數(shù)據(jù)特性使用文件或API的收集方法。如大量用戶訪問情況下，前端服務(wù)接口會(huì)產(chǎn)生大量的數(shù)據(jù)，若使用文件收集的方法會(huì)影響到系統(tǒng)的磁盤IO，則應(yīng)使用API的收集方法。而與第三方服務(wù)交互處的數(shù)據(jù)收集則應(yīng)使用文件的收集方法，因?yàn)榈谌浇换?shù)據(jù)的收集可靠性要求較高，使用文件保存數(shù)據(jù)穩(wěn)定、可靠。

文件或API的收集方法對(duì)開發(fā)人員而言是透明的，使用統(tǒng)一的API形式。這樣方便了開發(fā)人員集成數(shù)據(jù)收集功能到業(yè)務(wù)模塊中，不需要了解數(shù)據(jù)收集機(jī)制、數(shù)據(jù)格式、數(shù)據(jù)文件管理等。

1.3 數(shù)據(jù)格式

開發(fā)人員通過API的方式集成數(shù)據(jù)收集模塊，不需要關(guān)心采集的數(shù)據(jù)格式，只需要了解API參數(shù)的含義，而API底層則需要處理數(shù)據(jù)格式。對(duì)于文件收集方法，寫入文件的是多行JSON字符串；對(duì)于API收集方法，發(fā)送至Kafka的是JSON格式數(shù)據(jù)。從Kafka到Logstash再到Elasticsearch傳送也都是JSON格式數(shù)據(jù)。因此整個(gè)數(shù)據(jù)傳送過程中都使用JSON格式數(shù)據(jù)，數(shù)據(jù)格式清晰、不容易出錯(cuò)。

1.4 數(shù)據(jù)定義

數(shù)據(jù)定義決定了數(shù)據(jù)收集的內(nèi)容，是能否完成項(xiàng)監(jiān)控任務(wù)的前提。一般使用倒推的方法定義數(shù)據(jù)收集字段，即根據(jù)監(jiān)控需求分析出需要收集的數(shù)據(jù)內(nèi)容?；臼占侄稳绫?所示，使用這些基本字段可以對(duì)接口調(diào)用情況進(jìn)行統(tǒng)計(jì)以獲得監(jiān)控指標(biāo)，如根據(jù)“event_time”和“time_consumed”字段可以統(tǒng)計(jì)出在某個(gè)時(shí)間段執(zhí)行某項(xiàng)任務(wù)的平均時(shí)間。根據(jù)“event_time”，“task”，“result”字段可以統(tǒng)計(jì)出在某個(gè)時(shí)間段執(zhí)行某項(xiàng)任務(wù)的異常次數(shù)、異常率。

表1 數(shù)據(jù)收集的基本字段

在實(shí)際的應(yīng)用中基本字段往往還不能完全滿足監(jiān)控需求，這時(shí)需要對(duì)這些字段進(jìn)行擴(kuò)充以達(dá)到監(jiān)控要求。如需要對(duì)頁面的PV(訪問量)、UV(獨(dú)立訪客)進(jìn)行統(tǒng)計(jì)則需加入表2所示字段。

表2 頁面訪問相關(guān)字段

收集字段的定義需要統(tǒng)一規(guī)劃，可以預(yù)先定義部分未來可能會(huì)使用到的字段，這樣能有效地減少收集字段的調(diào)整次數(shù)。同時(shí)字段的調(diào)整也不可避免，為了方便后期維護(hù)字段名稱應(yīng)盡量確保無二義性，且清晰易懂。

1.5 Elasticsearch數(shù)據(jù)庫schema的設(shè)計(jì)

收集數(shù)據(jù)定義好之后便可以設(shè)計(jì)Elasticsearch數(shù)據(jù)庫的schema，schema中的字段可以直接使用收集數(shù)據(jù)定義的字段，需要指定字段的類型。Elasticsearch是一個(gè)基于Lucene構(gòu)建的開源、分布式、RESTful風(fēng)格的搜索引擎數(shù)據(jù)庫，已應(yīng)用到Github、Stack OverFlow等大型網(wǎng)站的全文搜索中[2]。搭建的Elasticsearch集群穩(wěn)定可靠、可以容納較大的數(shù)據(jù)量，符合存放業(yè)務(wù)數(shù)據(jù)的要求。

Elasticsearch schema中必須指定一個(gè)字段為時(shí)間字段，以此字段為線索構(gòu)成時(shí)間相關(guān)的事件序列，這里選擇event_time字段作為時(shí)間字段。在Elasticsearch中字符串字段有兩種類型：analyzed和非analyzed。analyzed字段為全文檢索字段，索引時(shí)會(huì)對(duì)文本進(jìn)行分詞處理；非analyzed字段為非全文檢索字段。Analyzed字段也不可以做聚合操作，若對(duì)此類型字段進(jìn)行聚合即是對(duì)文本分詞的結(jié)果進(jìn)行聚合，執(zhí)行效率很低。表3給出了各基本字段類型的配置，其中“time_consumed”字段需要進(jìn)行數(shù)值計(jì)算，如計(jì)算平均值，故設(shè)置為number類型；“result”、“system”、“module”、“task”和“result”字段為枚舉類型字段，故設(shè)置為非analyzed字段；“msg”和“error”字段中的值變化較大，包含的內(nèi)容多，故設(shè)置為analyzed字段。

表3 基本字段類型配置

1.6 監(jiān)控服務(wù)

1.6.1 監(jiān)控指標(biāo)

監(jiān)控?cái)?shù)據(jù)進(jìn)入Elasticsearch數(shù)據(jù)庫后，應(yīng)對(duì)其進(jìn)行定期的監(jiān)控指標(biāo)計(jì)算才能完成監(jiān)控功能。監(jiān)控指標(biāo)的計(jì)算是通過對(duì)收集數(shù)據(jù)的統(tǒng)計(jì)完成的，如要計(jì)算最近5分鐘執(zhí)行任務(wù)A的異常率，則需要統(tǒng)計(jì)出最近5分鐘執(zhí)行任務(wù)A的異常次數(shù)和總次數(shù)，再計(jì)算得出異常率；要計(jì)算最近5分鐘執(zhí)行任務(wù)B的平均時(shí)間，則需計(jì)算出“time_consumed”字段在最近5分鐘的均值。

監(jiān)控指標(biāo)的計(jì)算可以通過Elasticsearch統(tǒng)計(jì)API完成。統(tǒng)計(jì)API中的統(tǒng)計(jì)功能在Elasticsearch中完成，不需要先查詢數(shù)據(jù)再進(jìn)行統(tǒng)計(jì)，即方便了統(tǒng)計(jì)又提高了效率。監(jiān)控指標(biāo)主要分為三類：

1) 符合條件的次數(shù) 如監(jiān)控指標(biāo)為最近5分鐘執(zhí)行任務(wù)A的異常次數(shù)，這里條件為：(a)最近5分鐘；(b)執(zhí)行任務(wù)A；(c)執(zhí)行異常，則監(jiān)控指標(biāo)：

次數(shù)=符合條件a且條件b且條件c的記錄數(shù)

2) 符合條件的比例 如監(jiān)控指標(biāo)為最近5分鐘執(zhí)行任務(wù)B的異常率，這里條件為：(a)最近5分鐘；(b)執(zhí)行任務(wù)A；(c)執(zhí)行異常，則監(jiān)控指標(biāo)：

異常率 = 符合條件a且條件b且條件c的記錄數(shù)/符合條件a且條件b的次數(shù)

3) 符合條件的字段的平均值 如監(jiān)控指標(biāo)為最近5分鐘執(zhí)行任務(wù)C的平均時(shí)間，這里條件為：(a)最近5分鐘；(b)執(zhí)行任務(wù)C，則監(jiān)控指標(biāo)：

平均值=符合條件a且條件b的“time_consumed”字段的均值

這三類的統(tǒng)計(jì)都可以通過Elasticsearch的聚合計(jì)算完成，具體對(duì)應(yīng)關(guān)系舉例如表4所示。監(jiān)控指標(biāo)條件的設(shè)定較為靈活，結(jié)合不同字段的取值可以構(gòu)成復(fù)雜的統(tǒng)計(jì)，如：在最近5分鐘內(nèi)服務(wù)A中的模塊B在執(zhí)行任務(wù)C發(fā)生異常D的異常率。這些復(fù)雜的監(jiān)控指標(biāo)條件復(fù)雜但都能歸為上述定義的三類監(jiān)控指標(biāo)，可以通過Elasticsearch API統(tǒng)計(jì)得出，這得益于統(tǒng)計(jì)API的靈活和功能強(qiáng)大。

表4 監(jiān)控指標(biāo)與Elasticsearch查詢的對(duì)應(yīng)關(guān)系

1.6.2 監(jiān)控規(guī)則

監(jiān)控規(guī)則是由監(jiān)控指標(biāo)構(gòu)成的條件、執(zhí)行時(shí)間、行動(dòng)組成的。監(jiān)控指標(biāo)一般為數(shù)值類型如次數(shù)、比例、時(shí)間等，監(jiān)控條件則為指標(biāo)與閾值的比較，如異常次數(shù)大于100、異常比例大于10%、平均時(shí)間超過5秒等。執(zhí)行時(shí)間指定了什么時(shí)間執(zhí)行監(jiān)控規(guī)則，可以是周期性的，如每隔2分鐘。監(jiān)控行動(dòng)是指滿足監(jiān)控條件后所采取的動(dòng)作，通常有郵件通知、短信通知[5]等。當(dāng)行動(dòng)為通知時(shí)還包括了通知的內(nèi)容模板，內(nèi)容模板定義了如何向用戶傳送通知信息，如標(biāo)題、內(nèi)容及格式等。通知內(nèi)容可以包含Kibana鏈接，方便用戶對(duì)通知信息進(jìn)行進(jìn)一步的分析。一條典型的監(jiān)控規(guī)則如表5所示，使用的是郵件通知，并包含了郵件通知模板。

表5 監(jiān)控規(guī)則示例

2 關(guān)鍵技術(shù)

2.1 前端數(shù)據(jù)收集

前端數(shù)據(jù)收集是系統(tǒng)服務(wù)入口監(jiān)控的關(guān)鍵，能夠直接反應(yīng)用戶的使用情況、客戶端與網(wǎng)站的交互情況等[6]。由于Web、App都在用戶端，收集方法和后臺(tái)服務(wù)收集方法有所不同，需要建立專用通道收集數(shù)據(jù)，系統(tǒng)架構(gòu)如圖3所示。認(rèn)證與Session管理提供了認(rèn)證機(jī)制，防止服務(wù)被不可信方調(diào)用。并且為了防止數(shù)據(jù)被竊取和偽造，使用了HTTPS協(xié)議加密傳輸數(shù)據(jù)。前端收集服務(wù)處理前端數(shù)據(jù)的收集，把收集到的數(shù)據(jù)傳入Kafka，后續(xù)流程與后臺(tái)數(shù)據(jù)收集流程相同。由于傳入的流量大，前端收集服務(wù)需考慮負(fù)載均衡功能。部署多個(gè)前端收集服務(wù)，并配置加入負(fù)載均衡器。

圖3 前端數(shù)據(jù)收集

2.2 Elasticsearch Index的管理

Elasticsearch中的Index和傳統(tǒng)數(shù)據(jù)庫的表概念類似，采用單個(gè)或者多個(gè)Index取決于收集到的數(shù)據(jù)特征，如數(shù)據(jù)量、數(shù)據(jù)更新速度等。Index通常按照時(shí)間劃分存儲(chǔ)，如按天、月等。而查詢時(shí)則視多個(gè)按時(shí)間存儲(chǔ)的Index為同一Index，存儲(chǔ)的劃分對(duì)應(yīng)用是透明的[7]。按時(shí)間存儲(chǔ)的策略取決于對(duì)應(yīng)的數(shù)據(jù)特征，由于前端收集到的數(shù)據(jù)量較大，可以單獨(dú)配置Index，并按天存儲(chǔ)。而服務(wù)調(diào)用數(shù)據(jù)具有一定關(guān)聯(lián)性，數(shù)據(jù)特征相似，可以把所有服務(wù)調(diào)用數(shù)據(jù)配置到同一個(gè)Index，并按天存儲(chǔ)。調(diào)用第三方服務(wù)的數(shù)據(jù)特征和服務(wù)調(diào)用不同，可靠性要求高，且要求能夠進(jìn)行后期跟蹤、查詢，也需要單獨(dú)配置Index，由于數(shù)據(jù)量不大可以按月存儲(chǔ)。Elasticsearch提供了Index保留功能，超過保留時(shí)間的Index會(huì)自動(dòng)被刪除，這方便了Index的維護(hù)。Index具體配置如表6所示。

表6 Elasticsearch Index管理

2.3 監(jiān)控的高可用性要求

監(jiān)控服務(wù)需要加載所有的監(jiān)控規(guī)則，并在監(jiān)控規(guī)則指定的時(shí)間執(zhí)行監(jiān)控任務(wù)。監(jiān)控規(guī)則的數(shù)量和復(fù)雜度取決于用戶的配置和監(jiān)控需求，若需要執(zhí)行大量的監(jiān)控任務(wù)，則對(duì)運(yùn)行監(jiān)控任務(wù)的平臺(tái)提出了要求，如高可用性、性能等。監(jiān)控服務(wù)的高可用性要求是一項(xiàng)重要的基本要求，若監(jiān)控服務(wù)的不可用則會(huì)導(dǎo)致整個(gè)監(jiān)控系統(tǒng)的不可用，所以在設(shè)計(jì)時(shí)應(yīng)當(dāng)避免監(jiān)控服務(wù)的單點(diǎn)故障問題。Quartz是一個(gè)開源的作業(yè)調(diào)度框架，支持集群搭建，并提供負(fù)載均衡、可伸縮、高可用性等功能特性[8]。使用Quartz集群是解決監(jiān)控服務(wù)高可用要求的較好方法。Quartz分布式框架通過MySQL關(guān)系數(shù)據(jù)庫管理執(zhí)行的作業(yè)，確保單個(gè)任務(wù)同一時(shí)刻在一臺(tái)機(jī)器上運(yùn)行。在系統(tǒng)中Elasticsearch數(shù)據(jù)庫、MySQL數(shù)據(jù)庫都搭成集群模式，以保證系統(tǒng)的高可用性要求，部署結(jié)構(gòu)如圖4所示。

圖4 監(jiān)控服務(wù)的集群部署

3 實(shí)現(xiàn)與應(yīng)用示例

3.1 數(shù)據(jù)收集點(diǎn)的布置

本文介紹的監(jiān)控系統(tǒng)實(shí)際應(yīng)用到互聯(lián)網(wǎng)網(wǎng)站中，對(duì)網(wǎng)站入口、后臺(tái)服務(wù)的運(yùn)行、第三方服務(wù)的交互進(jìn)行了實(shí)時(shí)監(jiān)控。網(wǎng)站的系統(tǒng)架構(gòu)圖如圖5所示，其中虛線方框的模塊布置了數(shù)據(jù)收集點(diǎn)，包括了前端、前端服務(wù)、后端服務(wù)、部分中間件。前端數(shù)據(jù)收集服務(wù)、PHP層和數(shù)據(jù)訪問服務(wù)數(shù)據(jù)量大，使用API方式收集數(shù)據(jù)；業(yè)務(wù)服務(wù)、服務(wù)治理框架、調(diào)用第三方服務(wù)則使用文件方式收集數(shù)據(jù)?？蛻舳说谋O(jiān)控?cái)?shù)據(jù)通過前端收集服務(wù)收集；PHP層收集點(diǎn)包括了網(wǎng)站入口和后端服務(wù)入口監(jiān)控?cái)?shù)據(jù)的收集。業(yè)務(wù)服務(wù)間的調(diào)用監(jiān)控不需要在每個(gè)服務(wù)布置，而是把收集模塊集成到服務(wù)治理模塊中，這樣業(yè)務(wù)模塊則不需要增加額外處理邏輯來實(shí)現(xiàn)服務(wù)調(diào)用監(jiān)控。同時(shí)業(yè)務(wù)服務(wù)還布置了對(duì)中間件調(diào)用以及第三方服務(wù)調(diào)用監(jiān)控?cái)?shù)據(jù)的收集。

圖5 數(shù)據(jù)收集點(diǎn)部署

數(shù)據(jù)收集點(diǎn)的布置應(yīng)當(dāng)避免數(shù)據(jù)重復(fù)收集，如若服務(wù)調(diào)用方和被調(diào)用方都布置了收集點(diǎn)，則會(huì)造成服務(wù)調(diào)用監(jiān)控?cái)?shù)據(jù)重復(fù)，增加了數(shù)據(jù)庫存儲(chǔ)和監(jiān)控?cái)?shù)據(jù)的復(fù)雜度。在服務(wù)、中間件調(diào)用場(chǎng)景應(yīng)盡量把收集點(diǎn)布置在調(diào)用方處，這樣被調(diào)用方不可用、性能下降等異?？梢员槐O(jiān)控到。監(jiān)控API中的消息字段用戶后續(xù)的分析、追蹤問題，在集成時(shí)不應(yīng)存入無用、冗余、過長的信息。而Elasticsearch中的枚舉字段則應(yīng)由API內(nèi)部填入，避免程序員直接填寫，可以通過編程語言的枚舉類型實(shí)現(xiàn)。

3.2 監(jiān)控系統(tǒng)部署和配置

監(jiān)控系統(tǒng)采用了高可用部署，收集點(diǎn)處的Logstash進(jìn)程配置了服務(wù)管理器，可以在Logstash進(jìn)程異常退出時(shí)重啟進(jìn)程；Kafka搭建為集群模式，配置為兩個(gè)節(jié)點(diǎn)；Elasticsearch數(shù)據(jù)庫搭建為集群模式，配置為三個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)的存儲(chǔ)為2 TB。在Elasticsearch集群的一個(gè)節(jié)點(diǎn)上部署了Kibana服務(wù)，同時(shí)也配置了服務(wù)管理器；監(jiān)控服務(wù)部署在Quartz集群上，Quartz集群配置為兩個(gè)節(jié)點(diǎn)。存儲(chǔ)監(jiān)控配置和任務(wù)的MySQL數(shù)據(jù)庫則使用了主從模式配置。

3.3 監(jiān)控規(guī)則的配置

根據(jù)布置好的監(jiān)控點(diǎn)，可以配置的監(jiān)控規(guī)則分為四類：

(1) 網(wǎng)站入口的監(jiān)控 網(wǎng)站入口的運(yùn)行指標(biāo)直接關(guān)系到用戶體驗(yàn)，配置的優(yōu)先級(jí)較高。對(duì)接口異常次數(shù)、異常率、接口平均調(diào)用時(shí)間配置了監(jiān)控。配置了短信、郵件報(bào)警方式，可以第一時(shí)間通知相關(guān)人員。

(2) 服務(wù)調(diào)用的監(jiān)控 通過配置了服務(wù)接口的異常率、平均調(diào)用時(shí)間可以監(jiān)控內(nèi)部各服務(wù)的運(yùn)行情況，包括了服務(wù)不可訪問、服務(wù)異常、服務(wù)響應(yīng)時(shí)間長等。

(3) 第三方服務(wù)調(diào)用的監(jiān)控 由于第三方服務(wù)為外部系統(tǒng)，易發(fā)生服務(wù)不可訪問、網(wǎng)絡(luò)不穩(wěn)定等異常情況，故需要通過監(jiān)控及時(shí)了解異常情況并采取相應(yīng)措施。

(4) 服務(wù)內(nèi)部關(guān)鍵點(diǎn)的異常監(jiān)控 服務(wù)內(nèi)部的關(guān)鍵點(diǎn)監(jiān)控需要開發(fā)人員在關(guān)鍵處加入數(shù)據(jù)收集邏輯，對(duì)某些指標(biāo)進(jìn)行預(yù)先計(jì)算、處理，再傳入收集API。收集的數(shù)據(jù)內(nèi)容形式多樣，取決于業(yè)務(wù)監(jiān)控需求。

(5) 頁面訪問指標(biāo)(PV，UV)的監(jiān)控 頁面訪問指標(biāo)的監(jiān)控可以反饋業(yè)務(wù)功能的訪問、使用情況，對(duì)運(yùn)營及產(chǎn)品設(shè)計(jì)有著重要的作用[9]。根據(jù)收集點(diǎn)的布置情況可以實(shí)現(xiàn)具體某個(gè)頁面在不同條件下的PV，UV監(jiān)控，同時(shí)在Kibana中可以對(duì)歷史數(shù)據(jù)進(jìn)行統(tǒng)計(jì)、分析。

3.4 運(yùn)行效果

監(jiān)控系統(tǒng)在實(shí)際運(yùn)行中取得了較好的效果，能及時(shí)報(bào)警網(wǎng)站入口異常、服務(wù)運(yùn)行異常、第三方服務(wù)不穩(wěn)定、與第三方服務(wù)間網(wǎng)絡(luò)異常等異常情況。對(duì)頁面訪問指標(biāo)的監(jiān)控?cái)?shù)據(jù)的統(tǒng)計(jì)分析，實(shí)現(xiàn)了BI系統(tǒng)無法完成的復(fù)雜統(tǒng)計(jì)功能。

4 結(jié) 語

本文介紹的監(jiān)控系統(tǒng)在搜索引擎數(shù)據(jù)庫Elasticsearch、數(shù)據(jù)收集器Logstash、可視化搜索與分析平臺(tái)Kibana的基礎(chǔ)上，擴(kuò)充并完善了數(shù)據(jù)收集方法，提出了實(shí)時(shí)監(jiān)控的具體方法，并在運(yùn)用中不斷完善，逐漸形成了穩(wěn)定、可靠的監(jiān)控系統(tǒng)。系統(tǒng)的實(shí)際運(yùn)行效果較好，配置靈活方便、易于使用，對(duì)復(fù)雜軟件系統(tǒng)的監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)具有參考意義。

[1] 方曉晴.校園網(wǎng)站監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].大連：大連理工大學(xué),2013.

[2] 張一. 網(wǎng)站綜合監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].西安：西安電子科技大學(xué),2013.

[3] 王余應(yīng). Zabbix監(jiān)控系統(tǒng)[M]. 北京：電子工業(yè)出版社，2015.

[4] 庫賽, 羅格辛斯基. Elasticsearch服務(wù)器開發(fā)[M]. 蔡建斌,譯. 2版.北京：人民郵電出版社，2015.

[5] 王雪冰,胡宏偉,王炯煒,等. 基于短信報(bào)警的文件監(jiān)控系統(tǒng)研究與實(shí)現(xiàn)[J]. 微計(jì)算機(jī)信息,2009，25(30):66-67,15.

[6] 王雅坤. 電商網(wǎng)站用戶行為實(shí)時(shí)監(jiān)控系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京：北京交通大學(xué),2016.

[7] Lei X, Wang Z, He Y Z. The Data Management and Real-time Search Based on Elasticsearch[C]// International Conference on Computer, Mechatronics, Control and Electronic Engineering. 2015.

[8] 朱哲明.基于Quartz的消息溝通平臺(tái)的研究[D].北京：北京郵電大學(xué)，2015.

[9] 董冠軍.基于用戶瀏覽行為分析的Web前端頁面優(yōu)化方法研究[D]. 天津：南開大學(xué)，2015.

DESIGNANDIMPLEMENTATIONOFMONITORSYSTEMBASEDONLOGANALYSISPLATFORM

Wang Liqun Huang Bidong

(CollegeofSoftwareandArtDesign,NanjingInstituteofRailwayTechnology,Jiangsu210031,Nanjing,China)

This article introduces the design and implementation of monitoring system based on log analysis platform. There are many problems in complex software systems, such as the multi-type monitor point, the excessive monitoring points, the easy change of monitoring points and the large amount of monitoring data. Therefore, we propose a design and implementation method of monitoring system based on log analysis ELK platform. By reforming the log analysis ELK platform, the method of collection, storage, indexing, search and analysis in log processing is introduced into the design and implementation of monitoring system, which solves the problem existing in the traditional monitoring method. It presents a new idea for the design of the monitor system.

Monitor system Log analysis ELK Elasticsearch

2017-07-26。王力群，副教授，主研領(lǐng)域：軟件設(shè)計(jì)與開發(fā)技術(shù)與面向?qū)ο笤O(shè)計(jì)模式。黃必棟，工程師。

TP3

A

10.3969/j.issn.1000-386x.2017.12.030