騰訊 SNG 監控數據的創新應用

本文由 吳樹生 發表於 騰訊織雲公衆號

引言

監控是運維領域的重要組成部分，咱們把監控形容爲運維的眼睛、耳朵和嘴巴。整個運行的質量情況要靠監控來發現異常，經過告警來通知你們。在這裏，我將向你們分享SNG監控十年來變革背後的驅動因素和立體化的監控方案，最後給你們展現最新的智能監控的應用場景。

1、IDC異常案例

給你們分享一個最近的真實案例，2018年春節前的最後一個週末2月10號凌晨6點29分，已有同窗休假回家，大部分人還在被窩裏熟睡的時候，深圳某個機房的機架掉電。

直到7點20分，負責機房的同窗才告訴咱們機房的溫度異常升高。

26分的時候反饋溫度異常緣由是空調故障，須要幾個小時的恢復時間。

來看一下咱們的業務監控。6月21分業務視圖告警通知到業務運維同窗，6點30分，在10分鐘以內把相關業務的運維同窗召集起來，啓動了大範圍故障處理流程。

雖然業務在天津、上海和深圳這三地有容災策略，爲了保障業務的有效運行，在6點50咱們評估出影響的範圍，決定啓動業務遷移。7點40分受影響的業務全量恢復。

可見，告警的及時性和數據的準確性，對保障業務質量發揮了重要的做用。

一開始我作網絡管理系統OSS，當時管理1萬個節點的網元和交換機，就以爲這是很牛的事情。

當進入到互聯網的監控領域，管理的服務器的數量和節點數量達6萬個節點，系統已經不堪重負，常常出現誤判的狀況。

咱們花了大量時間作服務器監控的優化，對架構進行重構升級，到如今已經管理了20萬個節點。

在作完升級後，又踏上了移動化的浪潮，所以基於大數據體系作了應用層的監控。

當作完這部分，發現應用層監控能最快、最直接反應業務質量的，它是從應用層的角度去發現問題，觸達用戶，是最全面的用戶體驗，比下面兩層的準確性更高。

如今的業務場景都會作相關的容災設備，服務器掛一個其實不會影響業務，可是到底有沒有影響業務，從下面兩層很難判斷。由此咱們創建了從總體到局部的立體化全鏈路的監控體系。

監控在DevOps裏面的應用，隨着咱們運維理念的變化而變化。一開始監控主要爲運維服務，對運維的質量負責。同時也關注業務質量的變化，監控開始觸及產品發佈這個環節。對業務質量負責的同窗不只僅是業務運維，一個產品的好壞，開發一樣承擔了重要的責任。

產品若是失敗了，整個開發團隊也就失敗了。所以開發也開始來關注業務質量的監控數據，而且經過監控數據，對線上的業務架構進行優化。

從設計到開發的流程，咱們監控貫穿了整個的DevOps流程體系。

2、 三大驅動力

跟你們談一下背後升級的三個因素。一開始，咱們的服務節點跑在騰訊自研的IDC環境，機器大部分是實體機器，作的監控主要是網絡監控、服務器監控以及DNS、http，對咱們的業務來講，機器量已經足夠多了。

當咱們走入到「雲」環境的時候，須要管理的節點數量量忽然劇增到20萬，僅僅一年時間服務節點從6萬到20萬。

之前在獨立的IDC的相似私有云環境運行的時候，管理的對象的標識能夠用IP做爲惟一標識，當咱們進入到私有云環境，還涉及到海外的機房，也會去採購其餘廠商的雲服務，用IP已經不能惟一的標識一個服務節點了，這時候就涉及到混合雲如何標識一個服務節點的問題，這就促進了整個監控背後數據模型的變化。

另外，在這麼多服務器節點裏面，如何去準確的定位出問題，作一個集中化的操控，這個因素驅動了整個服務監控的架構升級。

這張圖是監控系統的微服務架構，對頂層提供了單機和視圖兩個存儲服務，對外提供了數據查詢的接口，在這個基礎上構建了畫圖服務、告警服務、統計服務。

這個架構裏面表現出來的問題在哪些地方呢？咱們的底層服務要考慮到容災和背後的特性，至少要準備這個狀況，下面的各服務節點的服務實例和量很是龐大，咱們必須經過事務流的角度來看，來明確獲知某一個請求是否異常。

右下角是UGC流程，從博客的發送到Web接收、到數據存儲，經歷了3個節點，這裏面涉及到多臺服務器，要查一個問題變得很是困難。

2010年移動化開始出現，到如今已經完成了移動化的改造，你們使用的頻率已經從PC和Web時代轉向手機，體驗發生了根本的變化，打開一個APP超過10秒時間基本上就會放棄。打開一個APP看視頻，若是頻繁的出現卡頓，會形成用戶劇烈的流失。

對咱們來講，關注的指標從當時的成功率到了用戶體驗，採集的數據量也發生了巨大變化。

咱們對服務器進行監控管理20萬個節點，數據量還可控。當咱們要處理2億用戶的數據的時候，監控系統架構須要作相關升級和改造了。

另外，國內的移動化環境形成了咱們須要有多維度的場景。

國內的網絡至少有移動、電信和聯通這三大運營商，他們的網絡是割裂開來的，而且各自的網絡質量不同，須要關注運營商的質量，還要關注咱們發佈的版本對機型的要求，這對多維度提出了更高的要求。

3、立體化監控方案

這張圖是咱們創建的立體化覆蓋體系。最下面是傳統監控使用的OS服務器網絡的監控。

在它之上是對數據層進行相關的數據訪問性能的採集。中間是邏輯處理和Web層，均可以歸入到服務器體系來。

新增的是用戶端監控，包括卡、慢、多維和輿情監控。輿情監控作的事情是：對於騰訊的QQ體系來講，有一些用戶可能會打騰訊的投訴電話，會對用戶的反饋進行記錄並作相關的文本分析，創建異常的指標，發出業務告警。

立體化監控數據如何採集，須要注意哪些地方？對於用戶端監控來講，關注最多的是H五、http的響應，DNS查詢耗時、TCP連接耗時等等。有不少開源的方案，把指標採集上報到接入端，也作了一個插件去採集CGI的響應狀況。

上面是靠用戶數據來驅動，另外還有撥測，是咱們業務主動的行爲。在每一個廠商的IDC機房都部署了撥測的服務，對這些CGI創建撥測任務，經過撥測的方式採集CGI的響應時間和不一樣廠商機房的CGI響應時間，這樣就能夠在第一時間知道上線的服務是否正常。

服務端監控有兩種方式，被動採集和主動探測。對於主機經過主動探測SNMP和IPMI的方式探測是否正常。

主機運行的服務用了侵入式API上報方式，相似於業務埋點，只須要上報一個特性，通過這個行數的次數或者處理分支的次數。API上報會對業務性能產生影響，原本代碼能跑10幾萬qps，監控上報以後降到5萬，相應的成本就增長。

這要怎麼解決呢？咱們在上面作了共享內存，上報的時候直接寫內存，數據採集使用原子操做，定時10秒一次的採集數據，報到後端的接入機，這樣API的調用次數能夠達到7000萬。也就是說，這種方式對程序性能的影響是最微弱的。

右上角是是單屬性的上報，這裏咱們看到只上報了一個特徵值，能夠用10多臺服務器扛住20萬臺服務器的上報量。對於多維度的上報，如右下角，是用多個key來組成一個維來上報。

這對後端帶來了新的挑戰，這裏key的組合數比上面單屬性成倍的增長，還用10多臺服務器就扛不住了。對於多維的上報，key和指標的聚合計算放在上報端的機器去作，API上面會按1分鐘的維度作聚合，聚合以後經過Agent傳出去，流量降了接近一半，性能可達80萬/秒。

對於數據層的監控，咱們最擔憂的問題是數據存儲不均勻，也就是解決數據傾斜的問題。這一塊的數據採集沒有啥辦法，只能依靠存儲自身內置的特性來採集。

上面說了下數據採集，接下來總結一下織雲監控的理念，最核心的是創建數據銀行。數據銀行要作到普適性，所以數據銀行的模型就必需要足夠抽象。咱們創建了三類數據模型：

• 第一類模型是海量KPI指標的TSDB存儲引擎，能夠達到每秒萬級別請求的毫秒級響應；

• 第二類模型是海量多維的OLAP-TSDB存儲引擎，它的複雜度比前面要求高不少，只能作到秒級的響應；

• 第三類模型是海量日誌存儲引擎。

咱們在內部作完預研和應用，把場景提煉出來，而後再傳遞出去。接下來跟你們介紹一下咱們的數據銀行是怎麼作的。

KPI型的TSDB，全部的數據均可以抽象幾個特性，一是時間，二是監控對象是什麼，這個對象能夠有不少個指標來表達，因此咱們把指標稱做特性。對象的值經過四個屬性來表達，就是KPI的對象數據存儲模型。

當咱們把這個場景用於服務端監控的時候，業務模型監控的對象是單機或者單個虛擬節點。咱們的業務是分佈式的服務，因此在單機上面還要再聚合成業務視圖。整個存儲數據上報以後，會先把數據寫到單機的內存裏面，只保留2天的數據，作熱查詢。據咱們統計，80%的數據應用查詢都是查詢2天內的數據，所以天天會定時的存儲到文件上。

另外，咱們還創建了對象和特性的存儲結構。數據層和數據應用層分離，提供proxy和worker的架構，數據計算層使用了類MR的方案來提供高效率的數據查詢，也就是萬併發下面的毫秒級查詢。內存的數據存儲採用了多階hash的共享內存結構。

OLAP的數據模型關的時間、對象拓展，拓展成一個維度的概念。舉個例子，某一個運營商的客戶端IP，能夠被認爲是運營商的維度，客戶端的請求還帶有相關的版本信息，以及對應接收段IDC的信息，這些信息都是維度。

指標就是客戶端的請求和請求的響應時間。由對象擴充到維度，前面一天百萬級的對象能夠存儲，如今有30億的維度組合的數據怎麼存呢？這時咱們選的是druid查詢。採用druid作存儲，有如下幾方面考慮：一是存儲成本低。

更重要的一點是，咱們監控系統的維護對象的減小，druid只有5個組件維護對象，而基於Hadoop體系，涉及到維護對象成倍的增長，對於監控系統開發人員來講，這些組件的學習成本也是不可承受的痛。對於這一塊，咱們不只僅是用，還作了相關的優化，一是壓測以後的druid調優，二是容災優化，三是控制成本。

咱們作LOG的時候是採用相關的開源組件來存儲業務上報日誌，當業務漸漸上線的時候，發現開源的方案扛不住。

你們知道，開源一開始用的時候很爽，可是深刻去用的時候，須要不斷的去改它的BUG，這會致使投入到開源裏面的時間比本身寫的時間還要多，成本高。假如說數據量是100T，用了開源的方案，加上索引的數據，數據量至少要乘上1.5。

爲了解決性能和成本的問題，咱們自研了一個LOG的查詢存儲服務。數據進來以後，它會按照key作查詢的分片，先放到數據緩存。若是直接寫入磁盤，磁盤也存不住，因此加了數據緩存，先把數據按照1M大小緩存成一個塊，而後放到服務器上，相關的塊的分段和數據放到這裏面來記錄。

數據讀取的時候，怎樣作到秒級的數據響應和低延遲的數據查詢呢？延遲是在數據緩存這一塊，由於要緩存1M的數據大小，若是上報的數據量小，須要等待很長時間到文件存儲。

爲了解決這兩個問題，一方面數據會從文件服務器上拿過來，另外一方面會從緩存模塊提取數據。建一個數據過濾模塊，專門負責數據的解壓和查詢。

對於這種方案，首先作到技術上的把控。二是架構上面維護對象和模塊要足夠少，畢竟一個團隊的精力有限。三是成本，通過這樣處理存儲成本下降了，查詢性能也有提高。

咱們的數據如何處理呢？在SNG裏面有各類考驗，上報的數據格式多樣，大多不是規範化、標準化的，畢竟前面有十多年的技術架構發展，相關的方案也不可以統一。

除了監控成本，還要考慮效率，咱們對整個過程作了數據的抽象，也就是數據的翻譯、過濾、統計、告警等功能，經過配置化的方式去實現，再轉化成頁面的配置化方式，提升效率。

也就是說，咱們對一個業務的支持，以前須要專業的開發大數據開發同窗一週時間完成開發，如今減小到產品開發同窗半小時完成業務監控的數據處理配置。

這裏有幾個比較有特點的點：一個是消息隊列，咱們以前用Kafka，因爲磁盤和機器不穩定，消息隊列變得不穩定。

後端數據處理流程若是異常了，若消息隊列在，會把以前擠壓的數據從新消費，要從新啓動，系統恢復時間須要三十分鐘。

如今咱們採用的方案是建設穩定的後端，若是後端異常，之前積累的數據都是能夠拋棄的，咱們要保證後面的數據。數據落地存儲以後，數據銀行提供一個查詢的API網關。

剛纔提到，對數據模型處理進行抽象。它的數據模型是如何創建的？全部的數據均可以表達爲原子數據列表，好比一行數據的第幾個字段，數據名稱是什麼、數據值是什麼，把這個成爲原始單元，而後去過濾、聚合和轉發，對這四類操做進行抽樣處理，最終依賴的實際上是Storm數據傳輸能力。

這裏有一個好處，假如哪一天Storm再也不維護了，咱們開發的這一塊代碼還能夠用新的框架去跑，由於它並不強依賴Storm的特性，僅僅用了Storm的傳輸特性。

咱們幾大平臺有monitor特性監控、哈勃多維監控、全鏈路日誌和告警平臺，其上都創建了統一的API層。在這個基礎上，各個業務運維團隊去構建場景化的監控。

統一API之上的東西是大有可爲的，運維的經驗沉澱就是最上面的這部分，並不須要掌握下面那麼專業的大數據處理的工具，把上面的場景開發構建起來。

4、智能監控應用場景

談AIOps，數據是前提，先得把數據銀行構建起來。有了數據該怎麼用、能夠怎麼用？咱們對監控目標進行全新的定義和闡釋。

• 全。要作到無盲點的覆蓋，剛纔我列舉的立體化監控體系裏面，每一層都要有監控。如今新的監控需求來了，要求的是全鏈路的監控，每個請求、每個處理節點都須要鏈路的狀態信息。

• 準。咱們一直在強調怎麼作到無誤告警，監控系統誤告太可能是有緣由的。這時候咱們除了作到無誤告以外，還要把異常根源給推導出來。

• 快。咱們追求的是數據的低延時，告警發現的速度快，分析也要足夠快。

告警檢測傳統的作法是經過閾值檢測。閾值檢測有什麼問題呢？

• 第一，告警不許。咱們統計了，告警的業務故障自動發現率40%。你們一般是敲着代碼再看監控系統有沒有異常，還會出現漏告警或者誤告警，閾值告警沒法解決這個問題。

• 第二，維護困難。業務的發展，須要持續開發代碼，業務發生變化，配置得不到變動，必然會致使大量告警出現。

• 第三，告警量大。咱們曾經人均一天收100條告警。有部分同窗我的的告警量達到1000條，一天有1440分鐘，每一分鐘都是在收告警，手機的耗電量和流量是很大的。

這裏涉及到無監督算法，咱們的張戎博士會給你們分享下的。

告警裏面若是帶上根源，此異常是根據某個數據服務異常致使的，處理效率會更快。從這張圖上看，告警異常的出現必定有時間相關性。

發生告警以後，異常的曲線和狀態也是出現的時間點，各類監控系統處理的告警密度和時延不同，可是這個持續的時間是相近的，由於有時間相關性。不只如此，還要知道鏈路的調用關係。

這個調用關係怎麼去作的呢？剛剛提到的微服務理念有模塊的調用關係和路由調用關係，咱們有配置信息。

沒有微服務的系統怎麼辦？經過定時抓包的方式，也能獲取到網絡的流量關係，再加上業務經驗和人工清洗的功能，以及一些AI算法，整理出一個帶圈中的調用關係對，裏面會疊加時間相關的告警，而後推薦出告警根源。

異常根因分析這個案例應用在多維監控的場景。以前咱們對成功率進行判斷，由於你們標準同樣。

我想說爲何運維的AI那麼難作？

圖片的AI和語音的AI有一個特色，就是標準是同樣的，與咱們人眼的視覺評判標準是相似的。而業務運維的AI難作，由於每一個業務的異常業務特性是不同的，也就是標準是各異的。

成功率的好處是成功率的標準是一致的，因此能夠找出異常維度的組合。

可是，不能只知足於這個反饋，會出現請求量卡頓數的異常，咱們要擴展到累計量的指標。異常分析推薦出來的準確率，要考慮到總量的權重和異常的權重。

還有一點是性能，咱們經過算法去計算出某個異常，無法像廣告系統那樣作離線計算，跑一個算法，等着晚上出結果，對運維來講，咱們但願能作到秒級的響應。

所以，對於異常根源的分析挑戰，一是通用性，二是準確率，三是性能。

上面介紹了三類應用場景，已經可以覆蓋咱們大部分運維監控的應用。接下來給你們講一下咱們運維智能監控的具體案例。

上面這張圖是咱們常常看到的一個KPI的曲線，也就是成功率的曲線。

在這裏8月31號21點發生了一個異常，若是這個數據的基點不是從97%看，而是從0開始看的話，是看不出這裏有異常的，它僅僅掉了2個百分點。

這是很是棒的，即便2個百分點或者零點幾個百分點的降低，咱們也可以識別出來，而且還能識別出微小降低的緣由。

上面的是如何作到的呢？靠人工的辦法，首先由全局從大到小的概念去看，先選一個最少的維度來看，看下面的成功率哪一個掉了。手機QQ的成功率在這個時間點最低，同時總的請求數佔比最大，毫無疑問，先分析手機QQ的每個維度。

算法是能夠模擬人的操做，可是怎麼去判斷成功率的這個權重呢？咱們是參考了微軟的一篇論文。分析完異常以後，咱們可看到空間點播業務異常，找到一些訪問碼，須要客戶端的同窗去查相關代碼，拿到這些信息仍是不夠的，還須要日誌。

在這個異常的點相關的信息上，咱們跟日誌掛鉤，跳轉到日誌的節點來看，這時候就有足夠多的信息來支持開發去定位和快速恢復問題。

謝謝你們。

做者介紹

吳樹生：騰訊高級工程師，負責騰訊SNG大數據監控平臺建設以及織雲多爲監控，近十年監控系統開發經驗，具備構建基於大數據平臺的海量高可用分佈式監控系統研發經驗。

歡迎你們關注騰訊織雲微信公衆號（TencentCOC），第一時間獲取更多運維技術實踐乾貨哦~