胡鶴，趙毅，牛鐵，曹榮強(qiáng)

中科院計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100190

引言

集群服務(wù)器系統(tǒng)通過高速網(wǎng)絡(luò)將多臺物理服務(wù)器連接起來提供服務(wù)，如高性能計(jì)算集群提供并行計(jì)算服務(wù)，云計(jì)算將物理服務(wù)器云化并組成集群提供網(wǎng)絡(luò)服務(wù)。集群含計(jì)算、網(wǎng)絡(luò)、存儲等基礎(chǔ)設(shè)施及部署在其上相關(guān)應(yīng)用，系統(tǒng)中既包含了基礎(chǔ)設(shè)施的底層運(yùn)行信息，也包含操作系統(tǒng)、中間件等中間層系統(tǒng)信息，還包含了業(yè)務(wù)過程的上層應(yīng)用日志信息。

為保障集群安全性、穩(wěn)定性和服務(wù)能力，保證業(yè)務(wù)不中斷，Xu[1]指出大型云計(jì)算集群需要密切監(jiān)測各項(xiàng)指標(biāo) (例如網(wǎng)頁瀏覽、在線用戶數(shù)量和訂單數(shù)量) 的Web 應(yīng)用程序，準(zhǔn)確地檢測異常和觸發(fā)排除故障手段。付曉毓[2]在高性能計(jì)算集群上將時(shí)間和空間上的相關(guān)事件聚類并統(tǒng)計(jì)分析失效事件之間的相關(guān)性。Liu[3]收集 SNMP、系統(tǒng)和應(yīng)用日志、網(wǎng)絡(luò)抓包數(shù)據(jù)、web 訪問日志等時(shí)間序列數(shù)據(jù)做統(tǒng)計(jì)分析，進(jìn)行系統(tǒng)的異常檢測。

監(jiān)控平臺能將各種來源數(shù)據(jù)的實(shí)現(xiàn)統(tǒng)一管理、統(tǒng)計(jì)分析和展現(xiàn)，提前對潛在系統(tǒng)宕機(jī)、網(wǎng)絡(luò)攻擊等風(fēng)險(xiǎn)進(jìn)行發(fā)掘、分析、判斷，及時(shí)發(fā)出報(bào)警，從而采取應(yīng)對措施降低風(fēng)險(xiǎn)。Jason Dixon[4]提出監(jiān)控平臺的基礎(chǔ)架構(gòu)，包括傳感器、匯聚模塊、分析引擎、存儲引擎、通知?？?、可視化模塊。Caskey Dickson[5]提出監(jiān)控告警平臺設(shè)計(jì)架構(gòu)從低到高分為 6 層，包括數(shù)據(jù)收集、數(shù)據(jù)處理統(tǒng)計(jì)、異常檢測、告警、數(shù)據(jù)存儲、告警展示。Uber[6]把大數(shù)據(jù)平臺用于監(jiān)控基礎(chǔ)設(shè)施和應(yīng)用服務(wù)的健康情況。Hu[7]用 Elasticsearch 監(jiān)視高性能計(jì)算集群基礎(chǔ)設(shè)施的運(yùn)行情況。

本文面向集群服務(wù)器系統(tǒng)監(jiān)控平臺的搭建方式，綜述當(dāng)前各種常見的監(jiān)控平臺架構(gòu)和組件，分析各類平臺在部署、數(shù)據(jù)規(guī)模、統(tǒng)計(jì)分析能力以及時(shí)效性等方面的不同。

1 監(jiān)控平臺分類及評價(jià)標(biāo)準(zhǔn)

1.1 平臺分類

將目前廣泛采用的集群服務(wù)器系統(tǒng)監(jiān)控告警平臺作為評價(jià)對象，按照平臺部署方式的不同，將監(jiān)控平臺分為基于傳統(tǒng) Web 框架[8-10]、基于數(shù)據(jù)索引[11]及基于大數(shù)據(jù)處理框架的監(jiān)控平臺[12]。

1.1.1 基于傳統(tǒng) Web 框架的監(jiān)控平臺

基于傳統(tǒng) Web 框架的監(jiān)控平臺，主要指Zabbix、Nagios、Ganglia 等開箱即用的開源監(jiān)控工具，提供了數(shù)據(jù)采集、展示集成化的解決方案。如圖1 所示，監(jiān)控系統(tǒng)服務(wù)器操作系統(tǒng)普遍采用Linux，服務(wù)器端 GUI 使用 PHP 開發(fā)，完成數(shù)據(jù)數(shù)據(jù)查詢、展示和告警，部署在 Apache 或 Nginx 中。采集的數(shù)據(jù)寫入數(shù)據(jù)庫，有 RRDTool 和關(guān)系型數(shù)據(jù)庫(RDBMS) 兩種方式。

1.1.2 基于數(shù)據(jù)索引的監(jiān)控平臺

圖1 基于傳統(tǒng) Web 框架的監(jiān)控平臺架構(gòu)Fig.1 Monitoring platform architecture based on traditional Web framework

基于數(shù)據(jù)索引的監(jiān)控平臺采用開源框架 ELK Stack 的解決方案，部署方式見圖2。ELK Stack 是開箱即用的工具，包括 Elasticsearch、Logstash 和Kibana[13]。Elasticsearch 為時(shí)間序列加數(shù)據(jù)檢索的高性能數(shù)據(jù)庫，分布式存儲監(jiān)控?cái)?shù)據(jù)，并將數(shù)據(jù)索引起來以便單條語句查詢、分組統(tǒng)計(jì)。由 Logstash 對終端 Beats 收集到的各種數(shù)據(jù)解析和格式化處理，生成在 ES 上存儲的JSON 格式。展示工具 Kibana 方便定制統(tǒng)計(jì)圖表，且能交互式查詢，管理員可放大與縮小分析的區(qū)間判斷故障。在不同的應(yīng)用場景，ELK 系統(tǒng)的構(gòu)架略有不同，比如說有的場景運(yùn)用到了Redis 或者 Kafka 來做消息隊(duì)列，以減輕 Logstash 的壓力，以防數(shù)據(jù)丟失。Beats 也可以直接將數(shù)據(jù)發(fā)送給 Elasticsearch，省略 Logstash 環(huán)節(jié)[14]。報(bào)警功能的實(shí)現(xiàn)通常需調(diào)用 Elasticsearch API 執(zhí)行查詢?nèi)蝿?wù)，根據(jù)查詢結(jié)果和指定聯(lián)系人，調(diào)用短信、郵件告警模塊實(shí)現(xiàn)即時(shí)報(bào)警。

1.1.3 基于大數(shù)據(jù)處理框架的監(jiān)控平臺

基于大數(shù)據(jù)處理框架的監(jiān)控的平臺并無開箱即用的工具，通常利用大數(shù)據(jù)處理框架 Hadoop/Storm/Spark 開發(fā)相應(yīng)組件，拼裝成個(gè)性化的解決方案[15]。

圖2 基于數(shù)據(jù)索引的監(jiān)控平臺架構(gòu)Fig.2 Monitoring platform architecture based on data index

如圖3 所示，需要監(jiān)控報(bào)警的數(shù)據(jù)由實(shí)時(shí)計(jì)算平臺 Storm、Spark streaming 過濾、解析、處理，匯聚之后寫入分布式存儲當(dāng)中，并供給前臺展現(xiàn)并觸發(fā)規(guī)則進(jìn)行報(bào)警。存儲采用 HDFS/HBase 集群，所有的實(shí)時(shí)計(jì)算結(jié)果數(shù)據(jù)、閾值數(shù)據(jù)、其他時(shí)間序列的數(shù)據(jù)都匯總到該存儲當(dāng)中。離線計(jì)算部分主要處理的是離線的數(shù)據(jù)表，用于定期數(shù)據(jù)統(tǒng)計(jì)，如日報(bào)、周報(bào)等，同時(shí)利用統(tǒng)計(jì)結(jié)果修改在線處理的規(guī)則。

1.2 評價(jià)標(biāo)準(zhǔn)

對于千節(jié)點(diǎn)以上的大規(guī)模集群，其基礎(chǔ)設(shè)施健康數(shù)據(jù)、用戶行為及相關(guān)日志數(shù)據(jù)每天產(chǎn)生的增量數(shù)據(jù)通常在 TB 級別，且包含許多無結(jié)構(gòu)、半結(jié)構(gòu)的運(yùn)維數(shù)據(jù)[16]。因此平臺對數(shù)據(jù)的存儲、處理、查詢能力是極大的挑戰(zhàn)。本文針對監(jiān)控平臺需滿足的技術(shù)要求，從以下三方面進(jìn)行分析和評價(jià)。

(1) 數(shù)據(jù)規(guī)模

監(jiān)控?cái)?shù)據(jù)需要多維度觀察，某一事件會產(chǎn)生多個(gè)相關(guān)聯(lián)數(shù)據(jù)，造成消息量的膨脹。在集群規(guī)模較大的情況下監(jiān)控平臺應(yīng)能應(yīng)對每日上 T 的增量數(shù)據(jù)的存儲，且部分結(jié)果數(shù)據(jù)可按需長久保留，滿足未來幾月或幾年的計(jì)算需求。

(2) 查詢與統(tǒng)計(jì)功能靈活性

圖3 基于大數(shù)據(jù)處理框架的監(jiān)控平臺架構(gòu)Fig.3 Monitoring platform architecture based on large data processing framework

數(shù)據(jù)的查詢需靈活快速響應(yīng)不同且多變的需求。首先根據(jù)某一個(gè)或幾個(gè)字段篩選出符合條件的單機(jī)數(shù)據(jù)。其次能夠圈定集合范圍，并支持特定的算子涵蓋運(yùn)維的需求，計(jì)算count、sum、avg、分位值、min和max。再次，能夠進(jìn)行多表的關(guān)聯(lián)，填充其他所需字段信息或者聚合其他字段信息。比如調(diào)用鏈監(jiān)控為了解網(wǎng)絡(luò)請求在各個(gè)分布式系統(tǒng)之間的調(diào)用情況，把相同請求的鏈路分揀出來組成一條完整的鏈路，從而根據(jù)入口 URL、應(yīng)用、服務(wù)的調(diào)用關(guān)系，找到請求處理瓶頸，定位錯(cuò)誤異常的根源位置。

3) 時(shí)效性

對業(yè)務(wù)可用性要求高的集群服務(wù)器系統(tǒng)，運(yùn)維數(shù)據(jù)的實(shí)時(shí)性非常重要。如當(dāng)線上出現(xiàn)問題需要排查的時(shí)候，對幾十億級別流量的線上系統(tǒng)故障持續(xù)1小時(shí)，損失是不可估量的。此類系統(tǒng)數(shù)據(jù)從產(chǎn)生到能夠查詢、展示結(jié)果的間隔要求在秒級。

2 基于傳統(tǒng) Web 框架的監(jiān)控平臺

2.1 主流開源項(xiàng)目

2.1.1 Zabbix

Zabbix 是集成的開源分布式監(jiān)控解決方案，提供了客戶端監(jiān)控代理、閾值匹配報(bào)警、模板、監(jiān)控?cái)?shù)據(jù)展示等功能，滿足用 SNMP、IPMI 等協(xié)議收集硬件設(shè)備、網(wǎng)絡(luò)、操作系統(tǒng)及應(yīng)用的各種數(shù)據(jù)。Zabbix 將所有歷史數(shù)據(jù)、趨勢和配置信息存儲在關(guān)系型數(shù)據(jù)庫中[17]。

Zabbix 將單個(gè)指標(biāo)單次檢測值與閾值的比較觸發(fā)告警，并自帶聚合的功能 Aggregation，提供了對事件頻率、事件持續(xù)時(shí)間和事件并發(fā)條件等數(shù)據(jù)做的一些基本的統(tǒng)計(jì)操作，比較常見的有 SUM (總和)、AVG (平均值)、Max (最大值)、TopN 等等。復(fù)雜的統(tǒng)計(jì)可使用 calculate 的監(jiān)控項(xiàng)，套用一些比較復(fù)雜的公式進(jìn)行計(jì)算。

Zabbix 可以通過自定義 key 的功能，實(shí)現(xiàn)監(jiān)控Zabbix 不提供的監(jiān)控功能。

2.1.2 Ganglia

Ganglia 是 UC Berkeley 發(fā)起的一個(gè)開源集群監(jiān)控項(xiàng)目，大約 90% 的各種規(guī)模的HPC 在使用該框架。Ganglia 的核心包含 gmond、gmetad 以及 Web 前端。主要是用來監(jiān)控系統(tǒng)性能，如 CPU、內(nèi)存、硬盤利用率，I/O 負(fù)載、網(wǎng)絡(luò)流量情況等，通過曲線很容易見到每個(gè)節(jié)點(diǎn)的工作狀態(tài)[18]。

與 Zabbix 不同，Zabbix 是詳細(xì)監(jiān)控集群中每臺服務(wù)器的運(yùn)行狀態(tài)，而 Ganglia 是將集群中的服務(wù)器數(shù)據(jù)進(jìn)行匯總?cè)缓蟊O(jiān)控。

Ganglia 分為 gmetad 服務(wù)器端和 gmond 客戶端，gmetad 采用 IPv4 D 類地址中的的組播進(jìn)行數(shù)據(jù)請求，只需發(fā)送一次請求包即可完成對所有 gmond的輪詢。

向 Ganglia 加入自定義 metric 有兩種方法，一種是通過命令行的方式運(yùn)行 gmetric，另一種是通過Ganglia 提供的面向 C 和 Python 的擴(kuò)展模塊，加入自定義的模塊支持。

Ganglia 采用 RRDtool 作為存儲工具，將數(shù)據(jù)存儲于輪詢數(shù)據(jù)庫 (Round Robin Database)。RRDTool是一個(gè)可以自動歸并數(shù)據(jù)的數(shù)據(jù)庫。這種數(shù)據(jù)存儲方案能使用戶對近期數(shù)據(jù)進(jìn)行詳細(xì)分析，并能用少量硬盤空間存儲數(shù)年的歷史數(shù)據(jù)。

2.1.3 Nagios

Nagios 由 Core 和 Plugin 構(gòu)成，Core 提供監(jiān)控的處理、任務(wù)調(diào)度、下發(fā)指令的功能，Plugin 執(zhí)行具體的監(jiān)控指令、返回監(jiān)控的結(jié)果。所有的監(jiān)控檢測和報(bào)警部分的代碼功能都由插件完成。Nagios 自帶的插件非常有限，大部分的監(jiān)控功能交給用戶或其他相關(guān)開源項(xiàng)目組實(shí)現(xiàn)[19]。

Nagios 僅僅是一款數(shù)據(jù)采集工具，安裝包不包含數(shù)據(jù)庫。只對監(jiān)控指標(biāo)的實(shí)時(shí)情況進(jìn)行判斷并報(bào)警，不保存歷史數(shù)據(jù)，因而不能查看歷史數(shù)據(jù)及趨勢。

Nagios 配置功能弱，添加監(jiān)控目標(biāo)、擴(kuò)展插件需要用手工或 Shell 腳本修改配置文件。

2.2 特點(diǎn)分析

2.2.1 存儲能力分析

監(jiān)控?cái)?shù)據(jù)的大部分是時(shí)間戳加數(shù)據(jù)值的組合，格式簡單，而基于 Web 框架的監(jiān)控平臺采用關(guān)系型數(shù)據(jù)庫存儲會造成性能上和擴(kuò)展性上的局限性。當(dāng)數(shù)據(jù)量陡增時(shí)，通常采用讀寫分離、分庫分表的方式存儲數(shù)據(jù)，但擴(kuò)展能力有限且極大增加了服務(wù)器成本。

其次，對于類似日志的非結(jié)構(gòu)化字符串，關(guān)系型數(shù)據(jù)庫只能存儲成時(shí)間戳加日志內(nèi)容的格式，無法對日志的做進(jìn)一步統(tǒng)計(jì)分析。

RRDTool 繪圖功能強(qiáng)大，自動歸并數(shù)據(jù)能用少量硬盤空間存儲數(shù)年的歷史數(shù)據(jù)，但生成的文件數(shù)隨著需求的增長而增加，易導(dǎo)致磁盤出現(xiàn)嚴(yán)重的IO 瓶頸；同時(shí)只能通過 rrd-tool 工具包提取數(shù)據(jù)，提取不靈活。

2.2.2 數(shù)據(jù)處理能力分析

時(shí)序數(shù)據(jù)記錄最原始的狀態(tài)變化信息，而系統(tǒng)更關(guān)心原始數(shù)據(jù)的統(tǒng)計(jì)值。如對服務(wù)器網(wǎng)絡(luò)流量的分析更關(guān)心流量的平均值、流量的總和或者流量的峰值。聚合是時(shí)序數(shù)據(jù)查詢和分析的最基本的功能。Nagios采用簡單的閾值匹配告警，易導(dǎo)致誤報(bào)。Zabbix 提供了 Aggregation 的聚合方式，對數(shù)據(jù)做簡單的統(tǒng)計(jì)工作，聚合能力有限。

關(guān)系型數(shù)據(jù)庫不適合每秒成百上千的數(shù)據(jù)量的查詢。Zabbix 提供了告警聚合功能，每次觸發(fā)告警都需要繁瑣的數(shù)據(jù)庫查詢操作。因此極易因數(shù)據(jù)庫 IO、server 性能問題，導(dǎo)致 proxy 卡頓、報(bào)警不及時(shí)等。

由于存儲格式的限制，基于 Web 框架的監(jiān)控平臺無法解決日志信息查詢統(tǒng)計(jì)的問題。

3 基于索引存儲的監(jiān)控平臺

3.1 主流開源項(xiàng)目

Elk 是 Splunk 項(xiàng)目的一個(gè)開源實(shí)現(xiàn)，最初是Elasticsearch，Logstash，Kibana 三大核心套件，隨著該系統(tǒng)的發(fā)展產(chǎn)生了輕量級的Beats 組件，專門用來收集終端 (集群中的機(jī)器) 上日志和數(shù)據(jù)[14]。

Logstash 是一個(gè)用來搜集，分析，過濾日志的工具。它支持幾乎任何類型的日志，包括系統(tǒng)日志、錯(cuò)誤日志和自定義應(yīng)用程序日志。它可以從許多來源接收日志，這些來源包括 syslog、消息傳遞 (例如rabbitmq) 和 jmx，它能夠以多種方式輸出數(shù)據(jù)，包括電子郵件、websockets 和 Elasticsearch。

Elasticsearch 是實(shí)時(shí)全文搜索和分析引擎，提供搜集，分析，存儲數(shù)據(jù)三大功能；是一套開放 REST和 Java API 等結(jié)構(gòu)提供高效搜索功能，可擴(kuò)展的分布式系統(tǒng)。它構(gòu)建于 Apache Lucene 搜索引擎庫之上。

Kibana 是一個(gè)基于 Web 的圖形界面，用于搜索、分析和可視化存儲在 Elasticsearch 指標(biāo)中的日志數(shù)據(jù)。它利用 Elasticsearch 的REST 接口來檢索數(shù)據(jù)，不僅允許用戶創(chuàng)建他們自己的數(shù)據(jù)的定制儀表板視圖，還允許他們以特殊的方式查詢和過濾數(shù)據(jù)?？梢酝ㄟ^ Kibana 做出不同的Dashboard 來實(shí)時(shí)的監(jiān)控集群的狀況，比如 CPU 利用率，內(nèi)存的使用情況，集群的Job/Task 完成情況等。

Beats 負(fù)責(zé)在終端收集日志和數(shù)據(jù)，目前 Beats有好幾種，包括 Filebeat、Packetbeat、Metricbeat、Winlogbeat、Topbeat 等，用戶還可以借助 Libbeat來開發(fā)自己的Beat。Filebeat 功能相當(dāng)于 Logstashforwarder，用在收集文件日志。Packetbeat 用來收據(jù)網(wǎng)絡(luò)方面的數(shù)據(jù)。Topbeat 已經(jīng)合并到 Metricbeat里面，用來收集系統(tǒng)或者某個(gè)指定的服務(wù)所占用的Metrics，Winlogbeat 用來收集 Windows 系統(tǒng)上的日志信息。目前，已經(jīng)有數(shù)十種 Community Beats，可供下載使用。

3.2 特點(diǎn)分析

3.2.1 存儲能力分析

Elasticsearch 是面向文檔的，存儲整個(gè)對象或文檔，而且索引每個(gè)文檔的內(nèi)容使之被檢索。文檔以JSON 數(shù)據(jù)格式格式進(jìn)行存儲。這種存儲方式打破了傳統(tǒng)關(guān)系型數(shù)據(jù)庫的范式約束，更為靈活。

Elasticsearch 集群共享數(shù)據(jù)并提供故障轉(zhuǎn)移和擴(kuò)展功能，支持上百個(gè)節(jié)點(diǎn)的線性擴(kuò)展。當(dāng)有新的節(jié)點(diǎn)加入或者刪除節(jié)點(diǎn)，集群會感知到并平衡數(shù)據(jù)。

3.2.2 數(shù)據(jù)處理能力分析

Elasticsearch 是一款提供檢索以及相關(guān)度排序的開源框架，使用 POST 方式以 JSON 格式指定查詢條件，并為每個(gè)文檔建立倒排索引，提高了搜索查詢的速度，支持百億以上規(guī)模文檔的實(shí)時(shí)內(nèi)容搜索。早期單條語句查詢，通過關(guān)鍵字或者日志類型等查詢條件來快速的查看用戶感興趣的Log，以便快速的找出問題的根源，達(dá)到全天數(shù)據(jù)查詢的秒級響應(yīng)。

Elasticsearch 搜索出的數(shù)據(jù)均可用于統(tǒng)計(jì)[20]。其聚合工具最初只提供最簡單的分組 metric 統(tǒng)計(jì)，類似 SQL 的avg、max、min 等方法，無法支撐復(fù)雜SQL，多表關(guān)聯(lián)，嵌套 SQL 甚至自定義函數(shù)等功能。從版本 5 開始支持對存儲的文檔進(jìn)行復(fù)雜的bucket 統(tǒng)計(jì)，類似 SQL 的group by，支持?jǐn)?shù)據(jù)聚合、結(jié)果分類、嵌套查詢、相似性查詢、基于腳本的數(shù)據(jù)編程查詢等。因此可針對某一主機(jī)或某一指標(biāo)分成 bucket，進(jìn)而求 metic 的計(jì)算值。

4 基于大數(shù)據(jù)處理框架的監(jiān)控平臺

4.1 在線和離線處理

大數(shù)據(jù)處理技術(shù)分為在線與離線處理兩條分支[21]。在線處理的場景是對源數(shù)據(jù)做階段性的連續(xù)處理，通過時(shí)間窗或自動判斷時(shí)間段的方式來控制事件流處理邏輯的激活，也稱流處理。Storm 和Spark Streaming 是實(shí)現(xiàn)該類型處理的主流框架。離線處理對長時(shí)間或海量的歷史數(shù)據(jù)進(jìn)行分析、統(tǒng)計(jì)和挖掘。Map-Reduce、Hive 和 Spark 是實(shí)現(xiàn)離線處理的主流框架。

在應(yīng)用場景中通常在線處理和離線處理相集成。實(shí)時(shí)數(shù)據(jù)交給在線處理系統(tǒng)來處理，而像機(jī)器學(xué)習(xí)、回歸測試和歷史查詢這樣的深度分析，則由離線分析系統(tǒng)處理。在線處理將數(shù)據(jù)源提交的數(shù)據(jù)進(jìn)行預(yù)處理，過濾數(shù)據(jù)并持久化到分布式存儲，給離線處理準(zhǔn)備數(shù)據(jù)。因此在線處理系統(tǒng)不但將擴(kuò)充后的數(shù)據(jù)提交給離線處理的深度分析系統(tǒng)，同時(shí)也接收離線分析系統(tǒng)的處理結(jié)果，如動態(tài)更新規(guī)則。

4.2 主流開源項(xiàng)目

4.2.1 Storm

Storm 是由 Twitter 開源的分布式、高容錯(cuò)流計(jì)算、實(shí)時(shí)計(jì)算框架，彌補(bǔ)了 Hadoop 批處理所不能滿足的實(shí)時(shí)要求。Storm 通常作為規(guī)則的分析計(jì)算及告警處理[22]。

在 Storm 中，先要設(shè)計(jì)一個(gè)用于實(shí)時(shí)計(jì)算的圖狀結(jié)構(gòu)即拓?fù)?(topology)。該拓?fù)鋵惶峤唤o集群，由集群中的主控節(jié)點(diǎn) (master node) 分發(fā)代碼，將任務(wù)分配給工作節(jié)點(diǎn) (worker node) 執(zhí)行。一個(gè)拓?fù)渲邪╯pout 和 bolt 兩種角色，其中 spout 發(fā)送消息，負(fù)責(zé)將數(shù)據(jù)流以 tuple 元組的形式發(fā)送出去；而 bolt 則負(fù)責(zé)轉(zhuǎn)換這些數(shù)據(jù)流，在 bolt 中可以完成計(jì)算、過濾等操作，bolt 自身也可以隨機(jī)將數(shù)據(jù)發(fā)送給其他 bolt。代碼數(shù)據(jù)處理邏輯實(shí)現(xiàn)兩種類，一個(gè)是 spout (數(shù)據(jù)源的流入)，一個(gè)是 bolt (數(shù)據(jù)處理節(jié)點(diǎn))，根據(jù)的具體邏輯實(shí)現(xiàn)指定接口[23]。

4.2.2 Esper

Esper 是基于 Java 開發(fā)的事件流處理 (ESP) 和復(fù)雜事件處理 (CEP) 引擎。其中 ESP 配合流處理的spout，激活相應(yīng)類別的規(guī)則從大量事件數(shù)據(jù)流中過濾，實(shí)時(shí)查詢有意義的信息；CEP 配合流處理的bolt，使用事件處理語言 EPL，該語言用 SQL 標(biāo)準(zhǔn)語言提供 SELECT、 FROM、WHERE、 GROUP BY、HAVING、ORDER BY 及 JOIN 等功能，完成對事件進(jìn)行排序、從事件屬性中分析數(shù)據(jù)、給事件分組，以及單獨(dú)處理事件屬性值等操作。此外，Esper 還提供了一種基于模式匹配的查詢，可以檢測出某種固定序列或格式的數(shù)據(jù)集，可以構(gòu)建一些業(yè)務(wù)場景非常復(fù)雜的查詢，還可以構(gòu)建具有時(shí)序邏輯的查詢等。CEP 從查詢結(jié)果中統(tǒng)計(jì)計(jì)算事件，對計(jì)算結(jié)果的二次事件封裝，形成新的事件流再重新推入 ESP、直接入庫或送Web 端顯示[24]。

4.2.3 HDFS 及 HBASE

HDFS 是運(yùn)用于大規(guī)模廉價(jià)商用機(jī)子集群上的文件存儲與傳輸系統(tǒng)，將需要存儲的大文件進(jìn)行分割，形成 Block 數(shù)據(jù)塊，從而完成大數(shù)據(jù)的存儲。針對 HDFS 并行讀寫的要求，HDFS 強(qiáng)化了處理的協(xié)同并發(fā)性，弱化了一致性的要求，同時(shí)加入寫入鎖的機(jī)制。

HBASE 是構(gòu)建在 HDFS 上的NOSQL 數(shù)據(jù)庫，面向列存儲[25]。利用 HBASE 技術(shù)可在廉價(jià) PC Server上搭建起大規(guī)模結(jié)構(gòu)化存儲集群，常用于存儲 Storm的數(shù)據(jù)做離線計(jì)算。

HBASE 列式數(shù)據(jù)庫是無模式的，每行都有一個(gè)可排序的主鍵 rowkey 和任意多的列，列可以根據(jù)需要動態(tài)的增加，同一張表中不同的行可以有截然不同的列。這種存儲方式適用于對一個(gè)或幾個(gè)字段進(jìn)行查詢。但是在非 rowkey 多條件查詢、數(shù)據(jù)分析、統(tǒng)計(jì)等場景下，數(shù)據(jù)分片后分布到很多臺機(jī)器上，必須去訪問集群中的每臺機(jī)器并在每臺機(jī)器上查詢很多條記錄。這些場景下就比較適合來用 Map-Reduce 來計(jì)算。

4.2.4 Map-Reduce

Map-Reduce 是由 Google 公司研究提出的一種面向大規(guī)模數(shù)據(jù)處理的并行計(jì)算模型和方法[26]。Map-Reduce 利用集群上多機(jī)器的優(yōu)點(diǎn)，讓“計(jì)算邏輯”(processing) 和“數(shù)據(jù)” (data) 放在同一個(gè)節(jié)點(diǎn)上。map 函數(shù)從數(shù)據(jù)庫中讀取記錄，然后輸出很多 keyvalue 對，reduce 函數(shù)則是接受擁有相同 key 的多個(gè)map 的輸出，然后把這些值合并。

對存在 HDFS 上的文件或 HBase 中的表進(jìn)行查詢和計(jì)算時(shí)，需要專業(yè)人員手工實(shí)現(xiàn) Map-Reduce 類，因此 Hadoop 家族實(shí)現(xiàn)了若干項(xiàng)目對 MapReduce 進(jìn)行封裝。其中 Hive 是建立在 HDFS 上的SQL 引擎，定義了專用的類 SQL 語言，可以用來查詢、存儲以及分析存儲在 HDFS 中的數(shù)據(jù)，為業(yè)務(wù)人員提供了SQL 方式查詢文件及數(shù)據(jù)。Hive 使得常用 SQL 的開發(fā)者能夠迅速生成報(bào)表、進(jìn)行數(shù)據(jù)清洗或數(shù)據(jù)分析。Mahout 用 MapReduce 實(shí)現(xiàn)了部分?jǐn)?shù)據(jù)挖掘算法，是機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘的分布式框架，如推薦、聚類、分類，解決了并行挖掘的問題。

4.2.5 Spark

Apache Spark 是以 RDD 為核心的迭代式計(jì)算框架，包括批處理、流式計(jì)算 Spark Streaming，及交互式計(jì)算 SQL 查詢 Spark 的工具 Spark SQL[27]。Spark RDD 把所有中間數(shù)據(jù)保存在內(nèi)存中，把一系列 map過程抽象成一些高級操作，簡化編程。Spark 不需要像 Map-Reduce 需要從外部存儲介質(zhì)里把數(shù)據(jù)讀入到內(nèi)存，提高了 IO 效率。

與 Storm 對比，Spark Streaming 的特點(diǎn)是準(zhǔn)實(shí)時(shí)的，它是對一個(gè)時(shí)間段內(nèi)的數(shù)據(jù)收集起來作為一個(gè)RDD 再處理，也即將流式計(jì)算分解成一系列短小的批處理作業(yè)。在實(shí)時(shí)性上，其實(shí) Storm 才算得是嚴(yán)格意義上的實(shí)時(shí)性。但 Spark Streaming 的技術(shù)棧里面可以與 Spark Core 和 Spark SQL 結(jié)合，可以對中間數(shù)據(jù)進(jìn)行批處理和交互性查詢。

Spark 的設(shè)計(jì)適合迭代計(jì)算，很多機(jī)器學(xué)習(xí)的開源項(xiàng)目都是基于 Spark 實(shí)現(xiàn)的如 MLlib，實(shí)現(xiàn)了一些常見的機(jī)器學(xué)習(xí)算法和實(shí)用程序，包括分類、回歸、聚類等。

4.3 特點(diǎn)分析

4.3.1 存儲能力分析

HDFS 會隨著數(shù)據(jù)量的增大自動水平切分?jǐn)U展，Spark、Hive 離線處理的數(shù)據(jù)存放于 HDFS 之上，數(shù)據(jù)可無限拓展至 PB 級。跟 Hadoop 的無縫集成保障了其數(shù)據(jù)可靠性 (HDFS) 和海量數(shù)據(jù)分析的高性能(Map-Reduce)。

4.3.2 數(shù)據(jù)處理能力分析

在線處理不論使用 Storm 還是 Spark Streaming，由于使用了規(guī)則引擎幾乎滿足了 SQL 的所有功能，因此能夠完成實(shí)時(shí)事件分組、統(tǒng)計(jì)計(jì)算、排序等操作。其提供的連接查詢功能，方便對同一事件流進(jìn)行時(shí)序分析，如在用戶行為跟蹤的場景下，能針對同一用戶查詢多個(gè)應(yīng)用的訪問記錄。同時(shí)，面對在事件監(jiān)控系統(tǒng)中經(jīng)常需要對事件反復(fù)進(jìn)行多次不同規(guī)則處理的情況，事件再處理設(shè)計(jì)將能夠很好的擴(kuò)展流處理引擎的復(fù)雜邏輯工作，并可以實(shí)現(xiàn)事件流的多次處理統(tǒng)計(jì)。因此能及時(shí)發(fā)現(xiàn)系統(tǒng)和用戶的異常行為，獲知系統(tǒng)風(fēng)險(xiǎn)并采取措施。Storm 處理一個(gè)事件可以達(dá)到亞秒級的延遲[28]，而 Spark Streaming 則有秒級的延遲[29]。

離線處理方面，Hive 和 Spark SQL 對 SQL 支持較為齊全，包括聚合、數(shù)據(jù)分組統(tǒng)計(jì)和連接等多種操作類型。其中多維連接查詢，適用于業(yè)務(wù)多維分析場景，方便用戶生成各種歷史統(tǒng)計(jì)報(bào)表。通常來說一個(gè)離線處理運(yùn)行時(shí)間從幾分鐘到幾小時(shí)不等，如果是百億規(guī)模的數(shù)據(jù)分析時(shí)間可能會達(dá)到數(shù)個(gè)小時(shí)。

不論是 Map-Reduce 處理框架和 Spark 處理框架，都具備智能化的處理能力，提供了大量成熟的機(jī)器學(xué)習(xí)算法和開源系統(tǒng)。如 MLlib 和 Mahout 提供了數(shù)據(jù)挖掘的算法包，包含廣義線性模型、推薦系統(tǒng)、聚類、決策樹和模式匹配等算法。首先可以依據(jù)經(jīng)驗(yàn)數(shù)據(jù)識別事件，將事件歸類、歸因；其次，可以動態(tài)調(diào)整告警規(guī)則；再次用于分析事件流和日志信息，從而找出異常的消息簇，異?？梢耘c某項(xiàng)運(yùn)維結(jié)果或者事件相聯(lián)系，從而分析出潛在的原因與癥結(jié)。

5 總結(jié)和結(jié)論

搭建集群服務(wù)器系統(tǒng)的監(jiān)控平臺,在平臺方案選擇時(shí)應(yīng)兼顧如下方面的需求:保證監(jiān)控平臺在數(shù)據(jù)量增大的情況下穩(wěn)定運(yùn)行，具有較高的可擴(kuò)展性；同時(shí)利于運(yùn)維人員分析運(yùn)行情況，靈活適應(yīng)運(yùn)維人員的各種查詢分析請求；能夠?qū)崟r(shí)地采集數(shù)據(jù)，并及時(shí)準(zhǔn)確的預(yù)測風(fēng)險(xiǎn)。

本文分析了服務(wù)器集群監(jiān)控的三類典型方案，并從數(shù)據(jù)規(guī)模、時(shí)效性、查詢與統(tǒng)計(jì)的靈活性、查詢性能與部署難易程度幾個(gè)關(guān)鍵維度進(jìn)行了深度對比分析。匯總對比情況見表1。

表1 監(jiān)控平臺對比項(xiàng)目匯總Table 1 comparison summary of monitoring platforms

集群服務(wù)器系統(tǒng)監(jiān)控平臺搭建方案應(yīng)根據(jù)監(jiān)控?cái)?shù)據(jù)規(guī)模、時(shí)效性要求、查詢和統(tǒng)計(jì)需求選擇方案。如監(jiān)控規(guī)模在不大，在千節(jié)點(diǎn)以內(nèi)，且沒有對日志的查詢分析需求，采用基于傳統(tǒng) Web 框架的方案最為簡便；若系統(tǒng)規(guī)模在萬節(jié)點(diǎn)左右，關(guān)系型數(shù)據(jù)庫已不能支持指標(biāo)和日志數(shù)據(jù)的存儲，應(yīng)考慮采用基于索引存儲和大數(shù)據(jù)的平臺搭建方案。如對系統(tǒng)日志有交互式查詢的需求，而對日志的查詢統(tǒng)計(jì)需求較簡單，且不準(zhǔn)備付出過多成本，則基于索引存儲的方案更適合。基于大數(shù)據(jù)處理框架的方案更適合應(yīng)用于對實(shí)效性要求非常高，且業(yè)務(wù)流程復(fù)雜，需要對多維度的指標(biāo)進(jìn)行統(tǒng)計(jì)分析的場景。同時(shí)，構(gòu)建在大數(shù)據(jù)處理框架之上的智能化的處理能力，對建立故障模型、用戶行為模型從而預(yù)測風(fēng)險(xiǎn)提供了有效方法。針對典型場景，也可將多個(gè)系統(tǒng)整合，發(fā)揮系統(tǒng)的各自優(yōu)勢，如將索引存儲和大數(shù)據(jù)框架整合，既滿足了統(tǒng)計(jì)分析的靈活性又能實(shí)現(xiàn)交換式的數(shù)據(jù)查詢[30]。鑒于本文范圍限制，主要綜述了集群服務(wù)器系統(tǒng)監(jiān)控平臺的架構(gòu)設(shè)計(jì)，下一步努力的方向是系統(tǒng)告警、故障定位的智能化處理方法。