作者介紹
朱祥磊，山東移動BOSS系統架構師，負責業務支撐系統架構規劃和建設。獲國家級創新獎1項、通訊行業級科技進步獎2項、移動集團級業務服務創新獎3項，申請發明專利13項。

一、背景

當前運營商業務支撐系統正向雲化發展，以某移動公司為例，近年先後進行了經分系統雲化、大資料系統建設、BOSS雲化，現正在進行CRM雲化，同時構建企業級資源池。經過幾年的探索，深刻感受到雲化給業務支撐系統帶來高效低成本的優點，但同時也對運維能力帶來了更高的要求，針對傳統架構下的運維管理模式已經越來越不適合雲化下的要求，主要表現在：

1）監控問題：所管理的機器和程序數量越來越多，呈現幾十倍增長，傳統運維由於機器數量小，監控都是基於點的，但是雲化後，點變為一個個叢集，且叢集內機器數量龐大，基於點的監控方式越來越難以滿足大量機器運維管理需要。

2）工具問題：隨著機器數量增加，基於指令碼或基於傳統的釋出變更工具難以適應叢集內大量機器運維的需要，無論在自動化程度、效率、靈活性、便捷性、安全管控等方面均存在問題，迫切需要改變，引入新的工具。

3）分析問題：資料助力運維，但是由於雲化後，針對運維的有價值資料或日誌分散在大量的機器叢集上，難以像傳統架構一樣實現集中化分析和呈現，需要研究解決在分散式雲化架構下的運維資料集中分析問題。

4）服務問題：“IT即服務”，隨著雲化的演進，對敏捷運維能力也提出了更高的要求，現有ITIL基於流程、按照不同專業展開的運維服務模式，難以適應雲化資源池所需的跨專業運維模式，需要改變。

二、解決方案

為應對雲化後運維模式帶來的挑戰，我們進行了積極的探索，參考網際網路企業做法，引入相關開源和商用軟體以及網際網路企業的運維理念，結合運營商實際，初步構建了一套面向雲化架構的視覺化運維體系，並初步進行了落地執行，取得了較好的效果。

整體架構圖如下：

下面將一一展開論述。

視覺化運維的核心要點之一是要解決視覺化業務監控度量的問題，我們經過近幾年對雲架構下各種監控手段和措施持續不斷的摸索、改造、優化和完善，逐漸建成一套基於平臺故障監控，平臺效能監控，應用程式碼級診斷，應用端到端和業務體驗監控於一體的多層級叢集式監控系統，如下圖：

第一級：業務體驗監控。是直接面向一線使用者感知的體驗監控，通過對使用者終端到服務端整條鏈路各個關鍵環節效能指標（如網路時延等）和各類錯誤進行全流程跟蹤、監控，及時發現使用者感知相關的各類問題。

第二級：應用端到端監控。通過構建業務支撐系統自身整體架構檢視，並對每個節點部署監控元素，利用聚合、分組機制，能直接發現系統各個環節各個渠道的問題，便於快速定位問題和影響面，能支援上千臺機器的叢集規模。

第三級：應用程式碼級診斷定位。在發現應用效能、故障需要進一步深入定位時，可通過程式碼級診斷定位手段實現程式碼跟蹤，快速確定真正問題點。

第四級：分散式平臺效能監控。針對成千上萬臺機器叢集規模的平臺效能實現快速部署，實時監控手段，針對叢集內平臺效能相關的各個指標實現直觀的判斷和監控。

第五級：雲平臺故障監控。針對成千上萬臺基礎裝置，如小型機、x86、虛擬機器等，構建統一的雲監控平臺，實現系統故障級別的管控。

通過構建上述五級監控，基本全涵蓋了從“一線使用者感知到後端運維”，從“應用整體檢視到程式程式碼內部”，從“平臺故障監控到平臺效能監控”，各個維度的監控。

第一級：業務體驗監控

目前支援業務體驗監控的方式有很多，如映象方式、代理方式、外掛方式等，我們經過測試驗證，最終選擇使用者端瀏覽器注入、服務端外掛捕捉方式實現雲化後的使用者體驗監控。相較其他方式，資料無丟失，度量更加真實可靠。

1、主要做法

上圖是整體架構圖，分散式代理負責向用戶瀏覽器下發監控外掛、收集使用者感知資料；擴充套件引擎負責對使用者感知資料處理和分析，最後在控制檯集中展現。

以實體廳為例，監控組網和實現原理如下圖所示。在Web伺服器或應用程式伺服器中啟動使用者體驗功能，會改變伺服器向用戶返回的具體內容，主要包括在響應使用者的頁面頭部增加了瀏覽器外掛指令碼的引用路徑，便於使用者在訪問任何頁面時均會載入瀏覽器外掛，這個過程稱為瀏覽器注入。該外掛的主要作用是：捕捉使用者行為及與伺服器的關聯關係、使用者行為的響應時間及可以量化的效能指標（Apdex）。

瀏覽器外掛實現了對頁面元素事件處理過程的抽象，首先，通過jQuery捕捉介面元素的單擊、滾動及鍵盤敲擊等具體行為，及該行為對應的伺服器請求；其次，對每一次使用者操作，外掛會記錄使用者真實的響應時間，響應時間再進一步細分為客戶端時間、網路時間和伺服器處理時間等。與網路流量解碼不同的是，代理方式無法獲取資料包在網路上傳輸的精確時間，而只能通過頻寬的實際評估計算出來，實現原理是：每5~10分鐘會從使用者瀏覽器自動傳送1~10k大小不等的檔案給服務端，根據響應時間評估頻寬大小，再按照實際頁面大小估算網路時間。

使用者體驗監控介面如下，以使用者訪問作為最小統計單位，得出使用者每一次訪問的感知情況，是滿意、可容忍還是失望。對於每一次失望的訪問可以呈現出具體原因，失望是因為哪一步操作而失望的。

在找到引起使用者失望的操作後，可以分析導致操作失望的原因，是網路份額還是伺服器份額。對於使用者感知較差的訪問，可以通過頻寬評估出使用者可能的頻寬大小，如下圖：

2、效果舉例

1）建立直觀的使用者感知評價體系。在使用者感知評價體系中，響應速度最為關鍵，基於使用者體驗的監控為評價體系提供了有效資料，如業務辦理操作複雜度、互動速度、業務辦理成功率和轉化率等，如下圖所示，某時段內業務的體驗詳細情況：

2）實現使用者訪問效能和地市服務質量的監控：

使用者體驗偏重使用者行為和相關業務的監控，為深入瞭解雲化架構下的應用各個環節的執行情況，提升維護工作效率，還需要構建一套面向全業務、全渠道、端到端的業務監控系統，用於整體業務監控檢視，實現領導檢視和運維檢視合一的架構。

我們通過引入TAP+開源資料庫（Mongodb）+Spark流處理技術，對雲伺服器上網路流量進行實時動態採集，根據程式碼規範和業務規則對資料進行過濾、排重，解碼，分析、計算和交易關聯，最終實現基於業務整體檢視級動態監控，為後端運維提供了快速、高效支撐。整體架構如下：

1、基本原理和實現過程：

1）業務配置：從業務渠道維度出發，根據業務訪問關係，梳理出系統部署圖和業務關係檢視，包括系統內部相互之間訪問關係、訪問埠，元件屬性，協議解碼等，如下面是能力開放平臺系統部署和應用訪問檢視：

2）資料採集和流處理：首先、系統通過自動部署探針捕獲所有監控雲伺服器端原始資料後進行初次過濾後統一匯聚到TAP交換中心，流處理中心會根據每個業務元件探針從TAP交換中心捕獲資料並轉換為原始資料包。其次、解碼器根據TCP會話標識（flowid）將不同元件的原始資料包關聯成一個完整的會話流，並根據編碼規範對關聯後資料包進行協議解碼生成原始交易記錄；最後、處理引擎根據已配置的業務規則對原始交易記錄進行業務資訊（如型別、渠道等關鍵字）提取、分析生成業務指標記錄並將結果傳給負責web展現引擎後入庫。

3）動態監控：負責指標展現引擎（exporter）獲取到資料後，將結果實時更新到前臺web相應元件，目前我們已經實現實現對NGCRM、客服，網廳、商城，短廳，一級BOSS，渠道便利店，終端管理平臺，移動工作臺，自助終端和能力開放平臺等關鍵業務渠道應用級監控：

4）指標統計：告警模組（alerter）輪詢資料庫中記錄根據業務配置基線和閥值生成趨勢報告和告警資訊。

2、主要特點

1）靈活、高效快速部署

應用檢視級監控以網路資料為依託，能夠自動發現應用元件之間連線性和訪問關係（如IP地址，服務埠，應用協議等），非常適合雲架構下的敏捷業務監控部署，整體步驟只需3步：

2）視覺化運維，快速定位

基於動態執行檢視可以實時捕捉並跟蹤所有元件指標波動（如業務量、成功率、響應時長等指標）和基線告警，相比傳統拉網式逐個排查方式，運維人員能夠快速、準確定位故障，資料指標還可以應用於服務質量評測和變化趨勢分析。

3）自動關聯，端到端跟蹤

通過不同應用元件間交易自動關聯，可以跟蹤深入到業務系統內部，詳細分析業務內部各應用之間互動執行軌跡和互動關係，實現問題回溯和快速定位，可基於手機號等業務關鍵字做深入挖掘分析：

4）智慧模擬告警，告警更準確

提供模擬器功能，可自動調整告警閾值，和歷史上發生問題的情況對比，最終得到比較合理的告警閾值。

無論是業務體驗監控，還是應用端到端監控，都是粗粒度監控，在很多情況下，如出現應用效能等，儘管能及時發現問題，但是如何解決定位，還需要更加細粒度的診斷手段。為此，我們引入基於程式碼級的業務監控手段，用於解決應用雲化後複雜的環境下的問題定位診斷場景。

1、整體架構

程式碼級監控系統基於JVMTI（虛擬機器工具介面）技術實現，整體架構如下圖所示，JVM是目前為止使用最多的跨平臺執行環境，在此基礎上構建JVMTI介面具有較好的底層植入能力，針對不同業務將JVMTI的介面封裝成感測器，並由代理外掛呼叫來捕獲程式碼級資料。

2、用於故障診斷及效能剖析

基於JVMTI的監控工具可以追蹤和監控任何一筆使用者請求在伺服器端的程式碼軌跡，通過對比堆疊上各層函式耗時，可以迅速找出執行熱點，並定位到效能問題的根因。同時，對呼叫的函式啟用出入引數捕獲，可以詳細瞭解業務執行時的快照，幫助定位業務層面的問題。下圖為我們JVMTI代理外掛部署邏輯圖。

應用場景舉例一：

在6月份通過程式碼級監控定位到智慧營銷平臺效能問題，通過便利店呼叫營銷平臺交易通常在1~2分鐘時間，消耗伺服器大量執行緒池資源，同時在營業系統呼叫便利店過程中，採用了同步阻塞式呼叫，多次對使用者體驗造成影響。CPU取樣分析發現91.6%的效能損耗發生在應用伺服器層，進一步深入到最底層呼叫找到程式試圖對一個超大的ArrayList進行遍歷導致執行效率低下，解決方案是：採用更高效的雜湊集合取代ArrayList，如下圖：

應用場景舉例二：

通過程式碼級監控發現低版本的log4j元件引發的執行緒死鎖，導致青島自助終端短時間無法登入，如下圖：

除了上述業務和應用監控手段外，為了對各叢集中成百上千臺機器和分割槽進行直觀高效的集中監控並告警，我們引入開源軟體Ganglia和Nagios並進行定製，構建了一套適合雲化的叢集式平臺效能監控系統。目前已經實現了對大資料叢集、BDS叢集、CRM共約520個節點的集中監控和告警，內容包括節點和服務狀態、資源利用率、網路、IO流量等指標，以及Hadoop和HBase的各項效能指標。通過個性化定製，還可以方便地增加其他需要關注的指標項。

1、雲化平臺效能監控系統的優勢

相比傳統的網管監控，以及其他諸如nmon等效能監控手段，我們構建的分散式雲平臺效能監控系統具有以下幾大優勢：

• 圖形化web介面，通過曲線對整個叢集中裝置的各項效能指標進行直觀的展示，便於分析問題，發現效能瓶頸。而不是單點的展示。
• 層次結構清晰，通過定義對節點和服務分組、分類，逐級檢查，適合大規模伺服器叢集。
• 儲存效能指標資料，方便統計分析、生成和匯出報表。
• 擴充套件性強，支援多種開發語言（shell、C++、Perl、Python、PHP等），使用者可以方便的根據需要定製監控專案。

2、效能監控系統架構

我們構建的雲化平臺效能監控系統採用開源軟體Ganglia（版本3.7.1-2）和Nagios（版本4.1.1）。前者主要負責收集、展示效能指標資料，後者則側重於告警機制。

1）Ganglia系統架構

ganglia主要有三個模組，如下圖所示。

• gmond：部署在各個被監控節點上，定期收集節點資料，並進行廣播或單播；
• gmetad：部署在伺服器端，定時從data_source中拉取gmond收集的資料。在每個叢集中選擇一個節點定義為data_source；
• ganglia-web：部署在伺服器端，將監控資料投遞到web頁面。

2）Nagios系統架構

Nagios主要包括nagios daemon、外掛（plugins）和NRPE模組，如下圖所示。

Nagios按照設定的週期呼叫外掛來檢查監控物件狀態。執行check_nrpe，並指定引數（檢查命令，比如check_disk）,告訴遠端被監控節點的NRPE daemon需要檢查哪些指標。NRPE 執行本地的各種外掛進行檢測，然後把檢測的結果返回給check_nrpe。伺服器端維持一個佇列，所有返回的狀態資訊都進入佇列。共有4種狀態資訊，即 0(OK)表示狀態正常/綠色、1(WARNING)表示出現警告/黃色、2(CRITICAL)表示嚴重錯誤/紅色、3(UNKNOWN)表示未知錯誤/深黃色。Nagios根據外掛返回來的值，判斷監控物件的狀態，並通過web展示。同時呼叫告警指令碼smswarn，傳送告警簡訊，同時，也可以配置郵件告警通知。

3）已實現的被監控節點列表

目前雲化平臺效能監控系統共監控如下節點，分為19個叢集：

3、雲化平臺效能監控效果

1）Ganglia效果示例

通過建立基於Ganglia的效能監控平臺，改變了對平臺效能監控的認識，大大提升了監控水平。

如下：一個介面內可以實現整個叢集的執行趨勢概況：

下面是雲集群內每個機器的執行情況，超過幾十種指標可選：

2）Nagios效果示例

解決了業務和平臺效能的監控問題，還有硬體和OS層面的監控問題需要解決，由於雲化的不斷深入發展，各類裝置很多，各種裝置特別x86快速增長，傳統監控方式、機房巡檢等方式維護難度越來越大，已無法滿足工作要求，為解決該問題，我們新建一套基於硬體和OS層故障的雲監控告警平臺，該告警平臺基於國際MIB標準，通過SNMP協議方式實現海量裝置故障資料自動採集，事件解析、分析，最終通過和BOMC融合實現業務資訊關聯和告警展現。

下圖是硬體告警平臺部署架構圖，最底層是包含各類被監控物件，包含各類裝置的硬體層面，第二層是硬體mib層，採用分散式架構，利用分散式採集、分散式snmp協議等技術實現海量硬體裝置的告警資料採集，第三層為故障解析和分析層，利用國際標準MIB進行故障解析、分析流程標準化，最上一層為展示層。

具體部署架構如下：

下面是幾個展示例項：

• 集中的故障展示：

• OS和虛擬機器層面詳細展示：

• hypervisor層儲存池監控：

文章出處：DBAplus社群（訂閱號ID：dbaplus）