騰訊 SNG 監控資料的創新應用

騰訊織雲發表於2019-03-01

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

引言

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

一、IDC異常案例

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

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

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

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

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

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

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

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

我們花了大量時間做伺服器監控的優化，對架構進行重構升級，到現在已經管理了20萬個節點。

在做完升級後，又踏上了移動化的浪潮，因此基於大資料體系做了應用層的監控。

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

現在的業務場景都會做相關的容災裝置，伺服器掛一個其實不會影響業務，但是到底有沒有影響業務，從下面兩層很難判斷。由此我們建立了從整體到區域性的立體化全鏈路的監控體系。

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

產品如果失敗了，整個開發團隊也就失敗了。因此開發也開始來關注業務質量的監控資料，並且通過監控資料，對線上的業務架構進行優化。

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

二、三大驅動力

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

當我們走入到“雲”環境的時候，需要管理的節點數量量突然劇增到20萬，僅僅一年時間服務節點從6萬到20萬。

以前在獨立的IDC的類似私有云環境執行的時候，管理的物件的標識可以用IP作為唯一標識，當我們進入到私有云環境，還涉及到海外的機房，也會去採購其他廠商的雲服務，用IP已經不能唯一的標識一個服務節點了，這時候就涉及到混合雲如何標識一個服務節點的問題，這就促進了整個監控背後資料模型的變化。

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

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

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

右下角是UGC流程，從部落格的傳送到Web接收、到資料儲存，經歷了3個節點，這裡面涉及到多臺伺服器，要查一個問題變得非常困難。

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

對我們來說，關注的指標從當時的成功率到了使用者體驗，採集的資料量也發生了巨大變化。

我們對伺服器進行監控管理20萬個節點，資料量還可控。當我們要處理2億使用者的資料的時候，監控系統架構需要做相關升級和改造了。

另外，國內的移動化環境造成了我們需要有多維度的場景。

國內的網路至少有移動、電信和聯通這三大運營商，他們的網路是割裂開來的，並且各自的網路質量不一樣，需要關注運營商的質量，還要關注我們釋出的版本對機型的要求，這對多維度提出了更高的要求。

三、立體化監控方案

這張圖是我們建立的立體化覆蓋體系。最下面是傳統監控使用的OS伺服器網路的監控。

在它之上是對資料層進行相關的資料訪問效能的採集。中間是邏輯處理和Web層，都可以納入到伺服器體系來。

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

立體化監控資料如何採集，需要注意哪些地方？對於使用者端監控來說，關注最多的是H5、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之上的東西是大有可為的，運維的經驗沉澱就是最上面的這部分，並不需要掌握下面那麼專業的大資料處理的工具，把上面的場景開發構建起來。

四、智慧監控應用場景

談AIOps，資料是前提，先得把資料銀行構建起來。有了資料該怎麼用、可以怎麼用？我們對監控目標進行全新的定義和闡釋。

全。要做到無盲點的覆蓋，剛才我列舉的立體化監控體系裡面，每一層都要有監控。現在新的監控需求來了，要求的是全鏈路的監控，每一個請求、每一個處理節點都需要鏈路的狀態資訊。
準。我們一直在強調怎麼做到無誤告警，監控系統誤告太多是有原因的。這時候我們除了做到無誤告之外，還要把異常根源給推匯出來。
快。我們追求的是資料的低延時，告警發現的速度快，分析也要足夠快。