基于日志分析平臺的監控系統的設計與實現

王力群 黃必棟

(南京鐵道職業技術學院軟件技術系 江蘇 南京 210031)

基于日志分析平臺的監控系統的設計與實現

王力群 黃必棟

(南京鐵道職業技術學院軟件技術系 江蘇 南京 210031)

介紹基于日志分析平臺的監控系統的設計與實現。針對復雜軟件系統的監控點類型多樣、監控點數量多、監控點易變化、監控數據量大等問題，提出一種基于日志分析平臺ELK的監控系統的設計與實現方法。通過對日志分析平臺ELK進行改造，把日志處理中的收集、存儲、索引、搜索、分析方法引入到監控系統的設計與實現中，解決了傳統監控方法存在的問題，為監控系統的設計提出了新的思路。

監控系統 日志分析 ELK Elasticsearch

0 引 言

穩定、可靠、高性能的軟件系統是以用戶大量使用及反饋為基礎，不斷滿足新需求，不斷完善和改進系統功能與性能，不斷演化系統架構與技術而形成。如互聯網系統，大量用戶的高并發訪問和使用，能及時反饋并發現問題，從而使系統不斷地進行調整、完善以滿足新的改進需求。而監控系統在發現問題、提高系統穩定性、分析系統性能等方面發揮著巨大的作用[1-2]。

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

本文介紹了一種基于日志分析平臺ELK的監控系統設計。日志分析平臺ELK是近年來迅速發展的開源日志分析平臺，包含了Elasticsearch全文檢索數據庫、Logstash日志收集器和Kibana可視化數據搜索、統計Web接口。監控系統以Logstash日志收集器為基礎擴展了業務數據收集方法，使用Elasticsearch存儲、索引業務運行數據，基于Elasticsearch API構建了監控模塊。解決了業務數據的收集難，存儲和分析困難的問題，提出了易擴展、可靈活配置和可快速搭建的監控系統框架。

1 架構設計

1.1 體系結構

監控系統的設計以ELK日志分析平臺為基礎，采用了Kafka消息隊列作為數據傳送緩沖器，實現了數據收集API、監控服務、監控Web接口，系統架構如圖1所示。

圖1 系統架構

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

1.2 數據收集

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

圖2 數據收集

根據收集的數據特性使用文件或API的收集方法。如大量用戶訪問情況下，前端服務接口會產生大量的數據，若使用文件收集的方法會影響到系統的磁盤IO，則應使用API的收集方法。而與第三方服務交互處的數據收集則應使用文件的收集方法，因為第三方交互數據的收集可靠性要求較高，使用文件保存數據穩定、可靠。

文件或API的收集方法對開發人員而言是透明的，使用統一的API形式。這樣方便了開發人員集成數據收集功能到業務模塊中，不需要了解數據收集機制、數據格式、數據文件管理等。

1.3 數據格式

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

1.4 數據定義

數據定義決定了數據收集的內容，是能否完成項監控任務的前提。一般使用倒推的方法定義數據收集字段，即根據監控需求分析出需要收集的數據內容。基本收集字段如表1所示，使用這些基本字段可以對接口調用情況進行統計以獲得監控指標，如根據“event_time”和“time_consumed”字段可以統計出在某個時間段執行某項任務的平均時間。根據“event_time”，“task”，“result”字段可以統計出在某個時間段執行某項任務的異常次數、異常率。

表1 數據收集的基本字段

在實際的應用中基本字段往往還不能完全滿足監控需求，這時需要對這些字段進行擴充以達到監控要求。如需要對頁面的PV(訪問量)、UV(獨立訪客)進行統計則需加入表2所示字段。

表2 頁面訪問相關字段

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

1.5 Elasticsearch數據庫schema的設計

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

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

表3 基本字段類型配置

1.6 監控服務

1.6.1 監控指標

監控數據進入Elasticsearch數據庫后，應對其進行定期的監控指標計算才能完成監控功能。監控指標的計算是通過對收集數據的統計完成的，如要計算最近5分鐘執行任務A的異常率，則需要統計出最近5分鐘執行任務A的異常次數和總次數，再計算得出異常率；要計算最近5分鐘執行任務B的平均時間，則需計算出“time_consumed”字段在最近5分鐘的均值。

監控指標的計算可以通過Elasticsearch統計API完成。統計API中的統計功能在Elasticsearch中完成，不需要先查詢數據再進行統計，即方便了統計又提高了效率。監控指標主要分為三類：

1) 符合條件的次數 如監控指標為最近5分鐘執行任務A的異常次數，這里條件為：(a)最近5分鐘；(b)執行任務A；(c)執行異常，則監控指標：

次數=符合條件a且條件b且條件c的記錄數

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

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

3) 符合條件的字段的平均值 如監控指標為最近5分鐘執行任務C的平均時間，這里條件為：(a)最近5分鐘；(b)執行任務C，則監控指標：

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

這三類的統計都可以通過Elasticsearch的聚合計算完成，具體對應關系舉例如表4所示。監控指標條件的設定較為靈活，結合不同字段的取值可以構成復雜的統計，如：在最近5分鐘內服務A中的模塊B在執行任務C發生異常D的異常率。這些復雜的監控指標條件復雜但都能歸為上述定義的三類監控指標，可以通過Elasticsearch API統計得出，這得益于統計API的靈活和功能強大。

表4 監控指標與Elasticsearch查詢的對應關系

1.6.2 監控規則

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

表5 監控規則示例

2 關鍵技術

2.1 前端數據收集

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

圖3 前端數據收集

2.2 Elasticsearch Index的管理

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

表6 Elasticsearch Index管理

2.3 監控的高可用性要求

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

圖4 監控服務的集群部署

3 實現與應用示例

3.1 數據收集點的布置

本文介紹的監控系統實際應用到互聯網網站中，對網站入口、后臺服務的運行、第三方服務的交互進行了實時監控。網站的系統架構圖如圖5所示，其中虛線方框的模塊布置了數據收集點，包括了前端、前端服務、后端服務、部分中間件。前端數據收集服務、PHP層和數據訪問服務數據量大，使用API方式收集數據；業務服務、服務治理框架、調用第三方服務則使用文件方式收集數據。客戶端的監控數據通過前端收集服務收集；PHP層收集點包括了網站入口和后端服務入口監控數據的收集。業務服務間的調用監控不需要在每個服務布置，而是把收集模塊集成到服務治理模塊中，這樣業務模塊則不需要增加額外處理邏輯來實現服務調用監控。同時業務服務還布置了對中間件調用以及第三方服務調用監控數據的收集。

圖5 數據收集點部署

數據收集點的布置應當避免數據重復收集，如若服務調用方和被調用方都布置了收集點，則會造成服務調用監控數據重復，增加了數據庫存儲和監控數據的復雜度。在服務、中間件調用場景應盡量把收集點布置在調用方處，這樣被調用方不可用、性能下降等異常可以被監控到。監控API中的消息字段用戶后續的分析、追蹤問題，在集成時不應存入無用、冗余、過長的信息。而Elasticsearch中的枚舉字段則應由API內部填入，避免程序員直接填寫，可以通過編程語言的枚舉類型實現。

3.2 監控系統部署和配置

監控系統采用了高可用部署，收集點處的Logstash進程配置了服務管理器，可以在Logstash進程異常退出時重啟進程；Kafka搭建為集群模式，配置為兩個節點；Elasticsearch數據庫搭建為集群模式，配置為三個節點，每個節點的存儲為2 TB。在Elasticsearch集群的一個節點上部署了Kibana服務，同時也配置了服務管理器；監控服務部署在Quartz集群上，Quartz集群配置為兩個節點。存儲監控配置和任務的MySQL數據庫則使用了主從模式配置。

3.3 監控規則的配置

根據布置好的監控點，可以配置的監控規則分為四類：

(1) 網站入口的監控 網站入口的運行指標直接關系到用戶體驗，配置的優先級較高。對接口異常次數、異常率、接口平均調用時間配置了監控。配置了短信、郵件報警方式，可以第一時間通知相關人員。

(2) 服務調用的監控 通過配置了服務接口的異常率、平均調用時間可以監控內部各服務的運行情況，包括了服務不可訪問、服務異常、服務響應時間長等。

(3) 第三方服務調用的監控 由于第三方服務為外部系統，易發生服務不可訪問、網絡不穩定等異常情況，故需要通過監控及時了解異常情況并采取相應措施。

(4) 服務內部關鍵點的異常監控 服務內部的關鍵點監控需要開發人員在關鍵處加入數據收集邏輯，對某些指標進行預先計算、處理，再傳入收集API。收集的數據內容形式多樣，取決于業務監控需求。

(5) 頁面訪問指標(PV，UV)的監控 頁面訪問指標的監控可以反饋業務功能的訪問、使用情況，對運營及產品設計有著重要的作用[9]。根據收集點的布置情況可以實現具體某個頁面在不同條件下的PV，UV監控，同時在Kibana中可以對歷史數據進行統計、分析。

3.4 運行效果

監控系統在實際運行中取得了較好的效果，能及時報警網站入口異常、服務運行異常、第三方服務不穩定、與第三方服務間網絡異常等異常情況。對頁面訪問指標的監控數據的統計分析，實現了BI系統無法完成的復雜統計功能。

4 結 語

本文介紹的監控系統在搜索引擎數據庫Elasticsearch、數據收集器Logstash、可視化搜索與分析平臺Kibana的基礎上，擴充并完善了數據收集方法，提出了實時監控的具體方法，并在運用中不斷完善，逐漸形成了穩定、可靠的監控系統。系統的實際運行效果較好，配置靈活方便、易于使用，對復雜軟件系統的監控系統設計與實現具有參考意義。

[1] 方曉晴.校園網站監控系統的設計與實現[D].大連：大連理工大學,2013.

[2] 張一. 網站綜合監控系統的設計與實現[D].西安：西安電子科技大學,2013.

[3] 王余應. Zabbix監控系統[M]. 北京：電子工業出版社，2015.

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

[5] 王雪冰,胡宏偉,王炯煒,等. 基于短信報警的文件監控系統研究與實現[J]. 微計算機信息,2009，25(30):66-67,15.

[6] 王雅坤. 電商網站用戶行為實時監控系統的設計與實現[D].北京：北京交通大學,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的消息溝通平臺的研究[D].北京：北京郵電大學，2015.

[9] 董冠軍.基于用戶瀏覽行為分析的Web前端頁面優化方法研究[D]. 天津：南開大學，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。王力群，副教授，主研領域：軟件設計與開發技術與面向對象設計模式。黃必棟，工程師。

TP3

A

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