當(dāng)前運(yùn)營(yíng)商業(yè)務(wù)支撐系統(tǒng)正向云化發(fā)展，以某移動(dòng)公司為例，近年先后進(jìn)行了經(jīng)分系統(tǒng)云化、大數(shù)據(jù)系統(tǒng)建設(shè)、BOSS云化，現(xiàn)正在進(jìn)行CRM云化，同時(shí)構(gòu)建企業(yè)級(jí)資源池。

　　一、背景

　　當(dāng)前運(yùn)營(yíng)商業(yè)務(wù)支撐系統(tǒng)正向云化發(fā)展，以某移動(dòng)公司為例，近年先后進(jìn)行了經(jīng)分系統(tǒng)云化、大數(shù)據(jù)系統(tǒng)建設(shè)、BOSS云化，現(xiàn)正在進(jìn)行CRM云化，同時(shí)構(gòu)建企業(yè)級(jí)資源池。經(jīng)過(guò)幾年的探索，深刻感受到云化給業(yè)務(wù)支撐系統(tǒng)帶來(lái)高效低成本的優(yōu)點(diǎn)，但同時(shí)也對(duì)運(yùn)維能力帶來(lái)了更高的要求，針對(duì)傳統(tǒng)架構(gòu)下的運(yùn)維管理模式已經(jīng)越來(lái)越不適合云化下的要求，主要表現(xiàn)在：

　　1)監(jiān)控問(wèn)題：所管理的機(jī)器和進(jìn)程數(shù)量越來(lái)越多，呈現(xiàn)幾十倍增長(zhǎng)，傳統(tǒng)運(yùn)維由于機(jī)器數(shù)量小，監(jiān)控都是基于點(diǎn)的，但是云化后，點(diǎn)變?yōu)橐粋�(gè)個(gè)集群，且集群內(nèi)機(jī)器數(shù)量龐大，基于點(diǎn)的監(jiān)控方式越來(lái)越難以滿足大量機(jī)器運(yùn)維管理需要。

　　2)工具問(wèn)題：隨著機(jī)器數(shù)量增加，基于腳本或基于傳統(tǒng)的發(fā)布變更工具難以適應(yīng)集群內(nèi)大量機(jī)器運(yùn)維的需要，無(wú)論在自動(dòng)化程度、效率、靈活性、便捷性、安全管控等方面均存在問(wèn)題，迫切需要改變，引入新的工具。

　　3)分析問(wèn)題：數(shù)據(jù)助力運(yùn)維，但是由于云化后，針對(duì)運(yùn)維的有價(jià)值數(shù)據(jù)或日志分散在大量的機(jī)器集群上，難以像傳統(tǒng)架構(gòu)一樣實(shí)現(xiàn)集中化分析和呈現(xiàn)，需要研究解決在分布式云化架構(gòu)下的運(yùn)維數(shù)據(jù)集中分析問(wèn)題。

　　4)服務(wù)問(wèn)題：“IT即服務(wù)”，隨著云化的演進(jìn)，對(duì)敏捷運(yùn)維能力也提出了更高的要求，現(xiàn)有ITIL基于流程、按照不同專業(yè)展開(kāi)的運(yùn)維服務(wù)模式，難以適應(yīng)云化資源池所需的跨專業(yè)運(yùn)維模式，需要改變。

　　二、解決方案

　　為應(yīng)對(duì)云化后運(yùn)維模式帶來(lái)的挑戰(zhàn)，我們進(jìn)行了積極的探索，參考互聯(lián)網(wǎng)企業(yè)做法，引入相關(guān)開(kāi)源和商用軟件以及互聯(lián)網(wǎng)企業(yè)的運(yùn)維理念，結(jié)合運(yùn)營(yíng)商實(shí)際，初步構(gòu)建了一套面向云化架構(gòu)的可視化運(yùn)維體系，并初步進(jìn)行了落地運(yùn)行，取得了較好的效果。

　　整體架構(gòu)圖如下：

　　下面將一一展開(kāi)論述。

　　三、監(jiān)控篇：實(shí)現(xiàn)多層級(jí)集群式業(yè)務(wù)監(jiān)控

　　可視化運(yùn)維的核心要點(diǎn)之一是要解決可視化業(yè)務(wù)監(jiān)控度量的問(wèn)題，我們經(jīng)過(guò)近幾年對(duì)云架構(gòu)下各種監(jiān)控手段和措施持續(xù)不斷的摸索、改造、優(yōu)化和完善，逐漸建成一套基于平臺(tái)故障監(jiān)控，平臺(tái)性能監(jiān)控，應(yīng)用代碼級(jí)診斷，應(yīng)用端到端和業(yè)務(wù)體驗(yàn)監(jiān)控于一體的多層級(jí)集群式監(jiān)控系統(tǒng)，如下圖：

　　第一級(jí)：業(yè)務(wù)體驗(yàn)監(jiān)控。是直接面向一線用戶感知的體驗(yàn)監(jiān)控，通過(guò)對(duì)用戶終端到服務(wù)端整條鏈路各個(gè)關(guān)鍵環(huán)節(jié)性能指標(biāo)(如網(wǎng)絡(luò)時(shí)延等)和各類錯(cuò)誤進(jìn)行全流程跟蹤、監(jiān)控，及時(shí)發(fā)現(xiàn)用戶感知相關(guān)的各類問(wèn)題。

　　第二級(jí)：應(yīng)用端到端監(jiān)控。通過(guò)構(gòu)建業(yè)務(wù)支撐系統(tǒng)自身整體架構(gòu)視圖，并對(duì)每個(gè)節(jié)點(diǎn)部署監(jiān)控元素，利用聚合、分組機(jī)制，能直接發(fā)現(xiàn)系統(tǒng)各個(gè)環(huán)節(jié)各個(gè)渠道的問(wèn)題，便于快速定位問(wèn)題和影響面，能支持上千臺(tái)機(jī)器的集群規(guī)模。

　　第三級(jí)：應(yīng)用代碼級(jí)診斷定位。在發(fā)現(xiàn)應(yīng)用性能、故障需要進(jìn)一步深入定位時(shí)，可通過(guò)代碼級(jí)診斷定位手段實(shí)現(xiàn)代碼跟蹤，快速確定真正問(wèn)題點(diǎn)。

　　第四級(jí)：分布式平臺(tái)性能監(jiān)控。針對(duì)成千上萬(wàn)臺(tái)機(jī)器集群規(guī)模的平臺(tái)性能實(shí)現(xiàn)快速部署，實(shí)時(shí)監(jiān)控手段，針對(duì)集群內(nèi)平臺(tái)性能相關(guān)的各個(gè)指標(biāo)實(shí)現(xiàn)直觀的判斷和監(jiān)控。

　　第五級(jí)：云平臺(tái)故障監(jiān)控。針對(duì)成千上萬(wàn)臺(tái)基礎(chǔ)設(shè)備，如小型機(jī)、x86、虛擬機(jī)等，構(gòu)建統(tǒng)一的云監(jiān)控平臺(tái)，實(shí)現(xiàn)系統(tǒng)故障級(jí)別的管控。

　　通過(guò)構(gòu)建上述五級(jí)監(jiān)控，基本全涵蓋了從“一線用戶感知到后端運(yùn)維”，從“應(yīng)用整體視圖到程序代碼內(nèi)部”，從“平臺(tái)故障監(jiān)控到平臺(tái)性能監(jiān)控”，各個(gè)維度的監(jiān)控。

　　第一級(jí)：業(yè)務(wù)體驗(yàn)監(jiān)控

　　目前支持業(yè)務(wù)體驗(yàn)監(jiān)控的方式有很多，如鏡像方式、代理方式、插件方式等，我們經(jīng)過(guò)測(cè)試驗(yàn)證，最終選擇用戶端瀏覽器注入、服務(wù)端插件捕捉方式實(shí)現(xiàn)云化后的用戶體驗(yàn)監(jiān)控。相較其他方式，數(shù)據(jù)無(wú)丟失，度量更加真實(shí)可靠。

　　1、主要做法

　　上圖是整體架構(gòu)圖，分布式代理負(fù)責(zé)向用戶瀏覽器下發(fā)監(jiān)控插件、收集用戶感知數(shù)據(jù);擴(kuò)展引擎負(fù)責(zé)對(duì)用戶感知數(shù)據(jù)處理和分析，最后在控制臺(tái)集中展現(xiàn)。

　　以實(shí)體廳為例，監(jiān)控組網(wǎng)和實(shí)現(xiàn)原理如下圖所示。在Web服務(wù)器或應(yīng)用程序服務(wù)器中啟動(dòng)用戶體驗(yàn)功能，會(huì)改變服務(wù)器向用戶返回的具體內(nèi)容，主要包括在響應(yīng)用戶的頁(yè)面頭部增加了瀏覽器插件腳本的引用路徑，便于用戶在訪問(wèn)任何頁(yè)面時(shí)均會(huì)加載瀏覽器插件，這個(gè)過(guò)程稱為瀏覽器注入。該插件的主要作用是：捕捉用戶行為及與服務(wù)器的關(guān)聯(lián)關(guān)系、用戶行為的響應(yīng)時(shí)間及可以量化的性能指標(biāo)(Apdex)。

　　瀏覽器插件實(shí)現(xiàn)了對(duì)頁(yè)面元素事件處理過(guò)程的抽象，首先，通過(guò)jQuery捕捉界面元素的單擊、滾動(dòng)及鍵盤(pán)敲擊等具體行為，及該行為對(duì)應(yīng)的服務(wù)器請(qǐng)求;其次，對(duì)每一次用戶操作，插件會(huì)記錄用戶真實(shí)的響應(yīng)時(shí)間，響應(yīng)時(shí)間再進(jìn)一步細(xì)分為客戶端時(shí)間、網(wǎng)絡(luò)時(shí)間和服務(wù)器處理時(shí)間等。與網(wǎng)絡(luò)流量解碼不同的是，代理方式無(wú)法獲取數(shù)據(jù)包在網(wǎng)絡(luò)上傳輸?shù)木�確時(shí)間，而只能通過(guò)帶寬的實(shí)際評(píng)估計(jì)算出來(lái)，實(shí)現(xiàn)原理是：每5~10分鐘會(huì)從用戶瀏覽器自動(dòng)發(fā)送1~10k大小不等的文件給服務(wù)端，根據(jù)響應(yīng)時(shí)間評(píng)估帶寬大小，再按照實(shí)際頁(yè)面大小估算網(wǎng)絡(luò)時(shí)間。

　　用戶體驗(yàn)監(jiān)控界面如下，以用戶訪問(wèn)作為最小統(tǒng)計(jì)單位，得出用戶每一次訪問(wèn)的感知情況，是滿意、可容忍還是失望。對(duì)于每一次失望的訪問(wèn)可以呈現(xiàn)出具體原因，失望是因?yàn)槟囊徊讲僮鞫�失望的�?/p>

　　在找到引起用戶失望的操作后，可以分析導(dǎo)致操作失望的原因，是網(wǎng)絡(luò)份額還是服務(wù)器份額。對(duì)于用戶感知較差的訪問(wèn)，可以通過(guò)帶寬評(píng)估出用戶可能的帶寬大小，如下圖：

　　2、效果舉例

　　1)建立直觀的用戶感知評(píng)價(jià)體系。在用戶感知評(píng)價(jià)體系中，響應(yīng)速度最為關(guān)鍵，基于用戶體驗(yàn)的監(jiān)控為評(píng)價(jià)體系提供了有效數(shù)據(jù)，如業(yè)務(wù)辦理操作復(fù)雜度、交互速度、業(yè)務(wù)辦理成功率和轉(zhuǎn)化率等，如下圖所示，某時(shí)段內(nèi)業(yè)務(wù)的體驗(yàn)詳細(xì)情況：

　　2)實(shí)現(xiàn)用戶訪問(wèn)性能和地市服務(wù)質(zhì)量的監(jiān)控：

　　第二級(jí)：應(yīng)用端到端監(jiān)控

　　用戶體驗(yàn)偏重用戶行為和相關(guān)業(yè)務(wù)的監(jiān)控，為深入了解云化架構(gòu)下的應(yīng)用各個(gè)環(huán)節(jié)的運(yùn)行情況，提升維護(hù)工作效率，還需要構(gòu)建一套面向全業(yè)務(wù)、全渠道、端到端的業(yè)務(wù)監(jiān)控系統(tǒng)，用于整體業(yè)務(wù)監(jiān)控視圖，實(shí)現(xiàn)領(lǐng)導(dǎo)視圖和運(yùn)維視圖合一的架構(gòu)。

　　我們通過(guò)引入TAP+開(kāi)源數(shù)據(jù)庫(kù)(Mongodb)+Spark流處理技術(shù)，對(duì)云服務(wù)器上網(wǎng)絡(luò)流量進(jìn)行實(shí)時(shí)動(dòng)態(tài)采集，根據(jù)代碼規(guī)范和業(yè)務(wù)規(guī)則對(duì)數(shù)據(jù)進(jìn)行過(guò)濾、排重，解碼，分析、計(jì)算和交易關(guān)聯(lián)，最終實(shí)現(xiàn)基于業(yè)務(wù)整體視圖級(jí)動(dòng)態(tài)監(jiān)控，為后端運(yùn)維提供了快速、高效支撐。整體架構(gòu)如下：

　　1、基本原理和實(shí)現(xiàn)過(guò)程：

　　1)業(yè)務(wù)配置：從業(yè)務(wù)渠道維度出發(fā)，根據(jù)業(yè)務(wù)訪問(wèn)關(guān)系，梳理出系統(tǒng)部署圖和業(yè)務(wù)關(guān)系視圖，包括系統(tǒng)內(nèi)部相互之間訪問(wèn)關(guān)系、訪問(wèn)端口，組件屬性，協(xié)議解碼等，如下面是能力開(kāi)放平臺(tái)系統(tǒng)部署和應(yīng)用訪問(wèn)視圖：

　　2)數(shù)據(jù)采集和流處理：首先、系統(tǒng)通過(guò)自動(dòng)部署探針捕獲所有監(jiān)控云服務(wù)器端原始數(shù)據(jù)后進(jìn)行初次過(guò)濾后統(tǒng)一匯聚到TAP交換中心，流處理中心會(huì)根據(jù)每個(gè)業(yè)務(wù)組件探針從TAP交換中心捕獲數(shù)據(jù)并轉(zhuǎn)換為原始數(shù)據(jù)包。其次、解碼器根據(jù)TCP會(huì)話標(biāo)識(shí)(flowid)將不同組件的原始數(shù)據(jù)包關(guān)聯(lián)成一個(gè)完整的會(huì)話流，并根據(jù)編碼規(guī)范對(duì)關(guān)聯(lián)后數(shù)據(jù)包進(jìn)行協(xié)議解碼生成原始交易記錄;最后、處理引擎根據(jù)已配置的業(yè)務(wù)規(guī)則對(duì)原始交易記錄進(jìn)行業(yè)務(wù)信息(如類型、渠道等關(guān)鍵字)提取、分析生成業(yè)務(wù)指標(biāo)記錄并將結(jié)果傳給負(fù)責(zé)web展現(xiàn)引擎后入庫(kù)。

　　3)動(dòng)態(tài)監(jiān)控：負(fù)責(zé)指標(biāo)展現(xiàn)引擎(exporter)獲取到數(shù)據(jù)后，將結(jié)果實(shí)時(shí)更新到前臺(tái)web相應(yīng)組件，目前我們已經(jīng)實(shí)現(xiàn)實(shí)現(xiàn)對(duì)NGCRM、客服，網(wǎng)廳、商城，短廳，一級(jí)BOSS，渠道便利店，終端管理平臺(tái)，移動(dòng)工作臺(tái)，自助終端和能力開(kāi)放平臺(tái)等關(guān)鍵業(yè)務(wù)渠道應(yīng)用級(jí)監(jiān)控：

　　4)指標(biāo)統(tǒng)計(jì)：告警模塊(alerter)輪詢數(shù)據(jù)庫(kù)中記錄根據(jù)業(yè)務(wù)配置基線和閥值生成趨勢(shì)報(bào)告和告警信息。

　　2、主要特點(diǎn)

　　1)靈活、高效快速部署

　　應(yīng)用視圖級(jí)監(jiān)控以網(wǎng)絡(luò)數(shù)據(jù)為依托，能夠自動(dòng)發(fā)現(xiàn)應(yīng)用組件之間連接性和訪問(wèn)關(guān)系(如IP地址，服務(wù)端口，應(yīng)用協(xié)議等)，非常適合云架構(gòu)下的敏捷業(yè)務(wù)監(jiān)控部署，整體步驟只需3步：

　　2)可視化運(yùn)維，快速定位

　　基于動(dòng)態(tài)運(yùn)行視圖可以實(shí)時(shí)捕捉并跟蹤所有組件指標(biāo)波動(dòng)(如業(yè)務(wù)量、成功率、響應(yīng)時(shí)長(zhǎng)等指標(biāo))和基線告警，相比傳統(tǒng)拉網(wǎng)式逐個(gè)排查方式，運(yùn)維人員能夠快速、準(zhǔn)確定位故障，數(shù)據(jù)指標(biāo)還可以應(yīng)用于服務(wù)質(zhì)量評(píng)測(cè)和變化趨勢(shì)分析。

　　3)自動(dòng)關(guān)聯(lián)，端到端跟蹤

　　通過(guò)不同應(yīng)用組件間交易自動(dòng)關(guān)聯(lián)，可以跟蹤深入到業(yè)務(wù)系統(tǒng)內(nèi)部，詳細(xì)分析業(yè)務(wù)內(nèi)部各應(yīng)用之間交互運(yùn)行軌跡和交互關(guān)系，實(shí)現(xiàn)問(wèn)題回溯和快速定位，可基于手機(jī)號(hào)等業(yè)務(wù)關(guān)鍵字做深入挖掘分析：

　　4)智能模擬告警，告警更準(zhǔn)確

　　提供模擬器功能，可自動(dòng)調(diào)整告警閾值，和歷史上發(fā)生問(wèn)題的情況對(duì)比，最終得到比較合理的告警閾值。

　　第三級(jí)：代碼級(jí)問(wèn)題診斷

　　無(wú)論是業(yè)務(wù)體驗(yàn)監(jiān)控，還是應(yīng)用端到端監(jiān)控，都是粗粒度監(jiān)控，在很多情況下，如出現(xiàn)應(yīng)用性能等，盡管能及時(shí)發(fā)現(xiàn)問(wèn)題，但是如何解決定位，還需要更加細(xì)粒度的診斷手段。為此，我們引入基于代碼級(jí)的業(yè)務(wù)監(jiān)控手段，用于解決應(yīng)用云化后復(fù)雜的環(huán)境下的問(wèn)題定位診斷場(chǎng)景。

　　1、整體架構(gòu)

　　代碼級(jí)監(jiān)控系統(tǒng)基于JVMTI(虛擬機(jī)工具接口)技術(shù)實(shí)現(xiàn)，整體架構(gòu)如下圖所示，JVM是目前為止使用最多的跨平臺(tái)運(yùn)行環(huán)境，在此基礎(chǔ)上構(gòu)建JVMTI接口具有較好的底層植入能力，針對(duì)不同業(yè)務(wù)將JVMTI的接口封裝成傳感器，并由代理插件調(diào)用來(lái)捕獲代碼級(jí)數(shù)據(jù)。

　　2、用于故障診斷及性能剖析

　　基于JVMTI的監(jiān)控工具可以追蹤和監(jiān)控任何一筆用戶請(qǐng)求在服務(wù)器端的代碼軌跡，通過(guò)對(duì)比堆棧上各層函數(shù)耗時(shí)，可以迅速找出執(zhí)行熱點(diǎn)，并定位到性能問(wèn)題的根因。同時(shí)，對(duì)調(diào)用的函數(shù)啟用出入?yún)��?shù)捕獲，可以詳細(xì)了解業(yè)務(wù)執(zhí)行時(shí)的快照，幫助定位業(yè)務(wù)層面的問(wèn)題。下圖為我們JVMTI代理插件部署邏輯圖。

　　應(yīng)用場(chǎng)景舉例一：

　　在6月份通過(guò)代碼級(jí)監(jiān)控定位到智能營(yíng)銷(xiāo)平臺(tái)性能問(wèn)題，通過(guò)便利店調(diào)用營(yíng)銷(xiāo)平臺(tái)交易通常在1~2分鐘時(shí)間，消耗服務(wù)器大量線程池資源，同時(shí)在營(yíng)業(yè)系統(tǒng)調(diào)用便利店過(guò)程中，采用了同步阻塞式調(diào)用，多次對(duì)用戶體驗(yàn)造成影響。CPU采樣分析發(fā)現(xiàn)91.6%的性能損耗發(fā)生在應(yīng)用服務(wù)器層，進(jìn)一步深入到最底層調(diào)用找到程序試圖對(duì)一個(gè)超大的ArrayList進(jìn)行遍歷導(dǎo)致執(zhí)行效率低下，解決方案是：采用更高效的哈希集合取代ArrayList，如下圖：

　　應(yīng)用場(chǎng)景舉例二：

　　通過(guò)代碼級(jí)監(jiān)控發(fā)現(xiàn)低版本的log4j組件引發(fā)的線程死鎖，導(dǎo)致青島自助終端短時(shí)間無(wú)法登錄，如下圖：

　　第四級(jí)：集群式平臺(tái)性能監(jiān)控

　　除了上述業(yè)務(wù)和應(yīng)用監(jiān)控手段外，為了對(duì)各集群中成百上千臺(tái)機(jī)器和分區(qū)進(jìn)行直觀高效的集中監(jiān)控并告警，我們引入開(kāi)源軟件Ganglia和Nagios并進(jìn)行定制，構(gòu)建了一套適合云化的集群式平臺(tái)性能監(jiān)控系統(tǒng)。目前已經(jīng)實(shí)現(xiàn)了對(duì)大數(shù)據(jù)集群、BDS集群、CRM共約520個(gè)節(jié)點(diǎn)的集中監(jiān)控和告警，內(nèi)容包括節(jié)點(diǎn)和服務(wù)狀態(tài)、資源利用率、網(wǎng)絡(luò)、IO流量等指標(biāo)，以及Hadoop和HBase的各項(xiàng)性能指標(biāo)。通過(guò)個(gè)性化定制，還可以方便地增加其他需要關(guān)注的指標(biāo)項(xiàng)。

　　1、云化平臺(tái)性能監(jiān)控系統(tǒng)的優(yōu)勢(shì)

　　相比傳統(tǒng)的網(wǎng)管監(jiān)控，以及其他諸如nmon等性能監(jiān)控手段，我們構(gòu)建的分布式云平臺(tái)性能監(jiān)控系統(tǒng)具有以下幾大優(yōu)勢(shì)：

　　圖形化web界面，通過(guò)曲線對(duì)整個(gè)集群中設(shè)備的各項(xiàng)性能指標(biāo)進(jìn)行直觀的展示，便于分析問(wèn)題，發(fā)現(xiàn)性能瓶頸。而不是單點(diǎn)的展示。

　　層次結(jié)構(gòu)清晰，通過(guò)定義對(duì)節(jié)點(diǎn)和服務(wù)分組、分類，逐級(jí)檢查，適合大規(guī)模服務(wù)器集群。

　　存儲(chǔ)性能指標(biāo)數(shù)據(jù)，方便統(tǒng)計(jì)分析、生成和導(dǎo)出報(bào)表。

　　擴(kuò)展性強(qiáng)，支持多種開(kāi)發(fā)語(yǔ)言(shell、C++、Perl、Python、PHP等)，用戶可以方便的根據(jù)需要定制監(jiān)控項(xiàng)目。

　　2、性能監(jiān)控系統(tǒng)架構(gòu)

　　我們構(gòu)建的云化平臺(tái)性能監(jiān)控系統(tǒng)采用開(kāi)源軟件Ganglia(版本3.7.1-2)和Nagios(版本4.1.1)。前者主要負(fù)責(zé)收集、展示性能指標(biāo)數(shù)據(jù)，后者則側(cè)重于告警機(jī)制。

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

　　ganglia主要有三個(gè)模塊，如下圖所示。

　　gmond：部署在各個(gè)被監(jiān)控節(jié)點(diǎn)上，定期收集節(jié)點(diǎn)數(shù)據(jù)，并進(jìn)行廣播或單播;

　　gmetad：部署在服務(wù)器端，定時(shí)從data_source中拉取gmond收集的數(shù)據(jù)。在每個(gè)集群中選擇一個(gè)節(jié)點(diǎn)定義為data_source;

　　ganglia-web：部署在服務(wù)器端，將監(jiān)控?cái)?shù)據(jù)投遞到web頁(yè)面。

　　2)Nagios系統(tǒng)架構(gòu)

　　Nagios主要包括nagios daemon、插件(plugins)和NRPE模塊，如下圖所示。

　　Nagios按照設(shè)置的周期調(diào)用插件來(lái)檢查監(jiān)控對(duì)象狀態(tài)。執(zhí)行check_nrpe，并指定參數(shù)(檢查命令，比如check_disk),告訴遠(yuǎn)端被監(jiān)控節(jié)點(diǎn)的NRPE daemon需要檢查哪些指標(biāo)。NRPE 運(yùn)行本地的各種插件進(jìn)行檢測(cè)，然后把檢測(cè)的結(jié)果返回給check_nrpe。服務(wù)器端維持一個(gè)隊(duì)列，所有返回的狀態(tài)信息都進(jìn)入隊(duì)列。共有4種狀態(tài)信息，即 0(OK)表示狀態(tài)正常/綠色、1(WARNING)表示出現(xiàn)警告/黃色、2(CRITICAL)表示嚴(yán)重錯(cuò)誤/紅色、3(UNKNOWN)表示未知錯(cuò)誤/深黃色。Nagios根據(jù)插件返回來(lái)的值，判斷監(jiān)控對(duì)象的狀態(tài)，并通過(guò)web展示。同時(shí)調(diào)用告警腳本smswarn，發(fā)送告警短信，同時(shí)，也可以配置郵件告警通知。

　　3)已實(shí)現(xiàn)的被監(jiān)控節(jié)點(diǎn)列表

　　目前云化平臺(tái)性能監(jiān)控系統(tǒng)共監(jiān)控如下節(jié)點(diǎn)，分為19個(gè)集群：

　　3、云化平臺(tái)性能監(jiān)控效果

　　1)Ganglia效果示例

　　通過(guò)建立基于Ganglia的性能監(jiān)控平臺(tái)，改變了對(duì)平臺(tái)性能監(jiān)控的認(rèn)識(shí)，大大提升了監(jiān)控水平。

　　如下：一個(gè)界面內(nèi)可以實(shí)現(xiàn)整個(gè)集群的運(yùn)行趨勢(shì)概況：

　　下面是云集群內(nèi)每個(gè)機(jī)器的運(yùn)行情況，超過(guò)幾十種指標(biāo)可選：

　　2)Nagios效果示例

　　第五級(jí)：平臺(tái)故障監(jiān)控

　　解決了業(yè)務(wù)和平臺(tái)性能的監(jiān)控問(wèn)題，還有硬件和OS層面的監(jiān)控問(wèn)題需要解決，由于云化的不斷深入發(fā)展，各類設(shè)備很多，各種設(shè)備特別x86快速增長(zhǎng)，傳統(tǒng)監(jiān)控方式、機(jī)房巡檢等方式維護(hù)難度越來(lái)越大，已無(wú)法滿足工作要求，為解決該問(wèn)題，我們新建一套基于硬件和OS層故障的云監(jiān)控告警平臺(tái)，該告警平臺(tái)基于國(guó)際MIB標(biāo)準(zhǔn)，通過(guò)SNMP協(xié)議方式實(shí)現(xiàn)海量設(shè)備故障數(shù)據(jù)自動(dòng)采集，事件解析、分析，最終通過(guò)和BOMC融合實(shí)現(xiàn)業(yè)務(wù)信息關(guān)聯(lián)和告警展現(xiàn)。

　　下圖是硬件告警平臺(tái)部署架構(gòu)圖，最底層是包含各類被監(jiān)控對(duì)象，包含各類設(shè)備的硬件層面，第二層是硬件mib層，采用分布式架構(gòu)，利用分布式采集、分布式snmp協(xié)議等技術(shù)實(shí)現(xiàn)海量硬件設(shè)備的告警數(shù)據(jù)采集，第三層為故障解析和分析層，利用國(guó)際標(biāo)準(zhǔn)MIB進(jìn)行故障解析、分析流程標(biāo)準(zhǔn)化，最上一層為展示層。

　　具體部署架構(gòu)如下：

　　下面是幾個(gè)展示實(shí)例：

　　集中的故障展示：

　　OS和虛擬機(jī)層面詳細(xì)展示：

　　hypervisor層存儲(chǔ)池監(jiān)控：