大家好，我是百度運維部平臺研發工程師顏志杰，畢業后一直在百度做運維平臺開發，先后折騰過任務調度(CT)、名字服務(BNS)、監控(采集&計算)；今天很高興和大家一起分享下自己做“監控”過程中的一些感想和教訓。

現在開始本次分享，本次分享的主題是《多維度數據監控采集&計算》，提綱如下，分為3個部分：

1.監控目標和挑戰

2.多維度數據監控

2.1.采集的設計和挑戰

2.2.聚合計算的設計和挑戰

2.3.高可用性保障設計

3.總結&展望

首先進入第一部分 ：監控目標和挑戰，先拋出問題，裝裝門面，拔高下分享的檔次(個人理解，歡迎challenge)。

監控期望做到：快速發現問題，定位問題(運維層面)，解決問題，甚至要先于問題發生之前，預測/防患未然，形成處理閉環，減少人工決策干預。

先解釋一下“定位問題(優先運維層面)”，意思是站在運維角度“定義故障”，不需要定位到代碼級別的異常，只需定位到哪種運維操作可以恢復故障即可，比如確定是變更引起的，則上線回滾，機房故障則切換流量等…

不是說監控不要定位到代碼級別的問題，事情有輕重緩急，止損是第一位，達到這個目標后，我們可以再往深去做。

再解釋下“預測/防患未然”，很多人第一反應是大數據挖掘，其實有不少點可以做，比如將變更分級發布和監控聯動起來，分級發布后，關鍵指標按照“分級”的維度來展示。(記住“分級”維度，先賣個關子:)

“監控目標”這個話題太大，挑戰多多。收斂一下，談一下我們在做監控時，遇到的一些問題，挑兩個大頭，相信其他在大公司做監控的同學也有同感：

1.監控指標多，報警多

2.報警多而且有關聯，如何從很多異常中找出“根因”

今天先拋出來兩個頭疼的問題，下面開始進入正題“多維度數據監控”，大家可以帶著這兩個問題聽，看方案是否可以“緩解”這兩個問題。

進入正題：

先看第一個問題：監控數據多。監控數據符合28定律，“關鍵”和“次要”指標需要區別對待，不能以處理了多大數據量引以為傲，需要按重要性分級處理，將資源傾斜到重要數據上分析和處理。

監控一個服務，把精力放在那20%的關鍵指標數據上，80%的次要指標作為出問題后，分析根因所用，如何采集關鍵指標，留到采集一章，下面以百度某產品線接入服務為例來說明“關鍵”指標處理有怎樣的需求。

下面以百度地圖產品線接入日志為例 (典型的nginx日志)：

223.104.13.177 - - [27/Jul/2015:16:08:21+0800] "GET /static/apisdk HTTP/1.1" 200 36224 "-""-" "Dalvik/1.6.0 (Android 4.4.2; HUAWEI MT7)" 0.0020501076098 223.104.13.177 10.202.19.40 10.202.68.25:8210 www.baidu.com 

百度地圖接入服務需要有這些監控：按照運營商、省份、省份&運營商pv/平響；不同urihttp_code在不同機房pv/平響， 請求手機操作系統版本的pv…

可以看到，一個指標會變為多個指標，比如pv監控項按照 5大運營商*36個省份 * 5個機房將產生900個指標數據，人工管理這種配置很困難，而且如果新增機房，需要新增配置5*36=180個配置，這個就不是人干的了。

同時，這些指標之間是相互關聯的，自然想知道地圖pv數據，在哪幾個運營商，省份，機房有數據，所以需要對監控項進行meta管理。

總結一下，“關鍵”指標數據需要多角度/多維度觀察，會一點變多點，這些多點數據有關聯，需要meta管理，簡單配置，那么如何來解決呢?

數據模型先行*3(重要的事情說三遍)，選擇一個好的數據模型來組織監控數據，解決上面提到的問題，將會有不同的效果，下面是兩種數據模型的優劣(也是我們自己的監控歷程)。

貼一下圖：

監控數據需要多角度觀察，這是強需求，在一維數據模型中，將維度信息放在了監控項名字里面，比如nginx_pv_city_beijing_isp_unicom表示的是北京聯通的pv，nginx_pv_city_beijing_isp_cmnet表示北京中國移動的pv。

這種數據模型，監控項間無關聯，除非對名字做一系列規定，并增加對名字做split操作之類，否則很難讓上面兩個數據產生關聯；而且配置的個數是維度的笛卡爾積。

參考aws的cloudwatch，有了多維度數據模型，通過tags來擴展維度，比如把運營商、省份放到tags字段里面，這樣用一份配置產生900關聯的監控數據；并加入了product字段，在數據分級，權限控制上有作用，后面再展開。

日志里面沒有運營商和省份，機房信息，是如何獲得的呢?這些我們統一叫做“運維元信息”，先賣個關子，待會在采集那一節展開，不過大家可以先有個印象，tags里面“維度”的取值可以做到很有“擴展性”。

所以結論是，監控數據符合28定律，重要數據需要多角度觀察，會產生多個相關聯數據，需要有meta管理，需要動態簡單配置。多維度數據模型可以很好的解決這些問題，內部我們將處理這數據模型的監控叫“多維度數據監控”。

多維度數據監控在處理/資源消耗上沒有減少，900個數據一個不少，所以我們將這套解決方案定位在處理“關鍵”數據，傾斜資源；而且只關注不同維度的聚合數據，單機數據在單機上存儲即可，這都是基于資源的考慮。

鋪墊了這么長，現在看看“多維度數據監控”的框架拆解：

典型的分層處理架構，采集=>計算=>存儲=>報警+展示，沒什么特別說的，想要強調2點：

1.數據模型先行，任何的一個層級只要符合“多維度數據模型”都可以獨立使用，每個層級都是服務化的。再強調一下“數據模型先行”。

2.聚合流式計算分布式架構，不暴露開源實現，開源之上都有適配層，很多的處理可以在適配層展開，這個好處在可用性章節具體展開。

下面開始依次介紹多維度采集&聚合計算&高可用性保證三個小節：

先介紹采集，如果大家對logstash熟悉那最好，采集agent很多功能點都是借鑒logstash來寫的，當然設計上有些改動，歡迎拍磚。

數據采集就是一個標準化的過程，服務以某種方式吐出數據，采集負責把數據轉換為監控數據模型，發往下游處理；所以理想情況是推監控標準，服務鏈接監控lib，lib將服務核心指標吐過來。

理想我們在努力中，然而… 所以，目前，關鍵指標大部分通過日志來獲取，遇到的挑戰是：

1.日志量大=>不傳原始日志，而且在agent做各種手段來減少數據傳輸。

2.日志如何規整化=>參考logstash，用命名正則來規整。

3.tags要做到很有‘擴展性’=> agent端需要支持對tag的自定義。

依次來說，第一如何降低數據傳輸，首先單機會做聚合，即一個周期內(如10s)，所有tags取值相同的監控會合成一條數據發送。比如百度地圖接入服務中，10s內來自北京聯通的請求變成一條監控數據，這個策略實踐證明對于減少數據是很明顯的。

數據減少手段還有ETL和公式計算，agent端就確定哪些數據是不用傳遞的，比如實現dict映射，只有在字典dict內的值才放行，其他的都歸結到other里面。

比如，運營商其實有20+，但一般OP就關注4大運營商，所以可以通過dict將其他的運營商都歸結到“other”里面，而且還支持重命名，既規整了tag的取值，又減少了數據的傳遞，比如有如下的dict：

"dict": [  
"CHINANET => 電信",  
"UNICOM => 聯通",  
"CMNET => 移動",  
"CRTC => 鐵通"  
] 

公式計算也如此，盡早的過濾不需要的數據，我們支持四則，邏輯運算，當agent端具備這樣的表達能力后，擴大了agent采集的能力，可以采集很多有意思的監控項：

比如根據nginx的響應時間${cost}和http錯誤碼${errno}，去定義損失pv，通過公式：${cost} > 2000 || ${errno} != 200 時間大于2s或errno不等于200，保證聚合計算功能純碎性，降低數據傳輸量。

第二個問題，日志如何規整化，通過命名正則來格式化文本日志，我們用c++寫的客戶端性能較logstash快不少，這里強調一下，我們沒有像logstash一樣可以支持多個線程去做正則，只有一個線程來計算，這樣做的考慮是：

正則匹配成功性能還可以，一般性能耗在不匹配的日志，出現不匹配的時候，正則會進行一些回溯算法之類的耗時操作，agent設計盡量少進入處理“不匹配日志”。

通過增加“前置匹配”功能，類似大家去grep日志的時候，“grep時間戳|grep–P ‘正則’ ”，字符串查找和正則匹配性能相差極大，agent端借鑒這個思想，通過指定字符串查找過濾，保證后面的日志基本都匹配成功，盡量避免進入“正則回溯”等耗時操作，在正確的地方解決問題。

這種設計保證agent最多占一個cpu。實踐證明，通過“前置匹配”，保證進入正則日志基本匹配成功，幾千qps毫無壓力，而且一般只占一個cpu核30%下。

第三個問題，Tag擴展性，tag是整個多維度監控的精髓，首先我們支持用戶自定義任何tag屬性，有統一的接口提供，你可以對監控數據上定義任何的tag，比如搜索服務里面可以加上庫層屬性。

前面提到的運營商、省份，這個通過在agent端用一個ip庫來實現反解，當然ip庫更新是一個問題，目前隨著agent的升級來進行更新，時效性不高。大家可以考下為何不放在server端處理:)

日志采集agent通過上面的一些手段，基本滿足了在關鍵指標的采集上的要求，完成了“標準化”，數據“精簡化”的需求。

總結一下，日志采集就是標準化的過程，通過采集配置將日志里面的信息變成多維度的數據模型，發送給后端模塊處理。

跟logstash比，想強調前置匹配功能點，沒有借鑒其多線程處理的設計，堅持單線程處理，如果監控需要消耗太多的資源去達到，那么我就對這個合理性存疑了。

采集就介紹到這，下面開始介紹實時匯聚計算。

前面提到，多維度數據監控不關注“單機”數據，只關注聚合數據，那首先第一個問題，怎么圈定“聚合"范圍?這塊功能在名字服務中實現，名字服務不展開。

如上圖，通過名字服務完成聚合范圍的圈定，支持三級范圍圈定(實例id=>服務=>服務組)，一個機器上的模塊稱為實例，實例發送的數據就是剛剛上面講的采集agent發出來的，每個數據都帶一個id標示，稱為實例id。

范圍圈定后，通過指定聚合規則，我們拼成一個聚合所需要的數據結構，這個數據是自包含的，即監控數據+聚合規則都包括在里面，如下圖所示：

將多維度數據+聚合配置變成聚合自包含數據，自包含數據包含了怎么對這個數據進行計算，上面標示要按照isp運營商匯聚，以及按照運營商和城市來匯聚。

有了聚合自包含數據后，就開始進行匯聚計算，如下圖所示：

首先我們只支持一些特定的運維算子，計算count、sum、avg、分位值、min/max基本上能涵蓋運維的需求，比如count就是pv，sum/avg/分位值算平響等。

遇到的挑戰包括：

1.單個匯聚的數據量過大，比如要計算10w機器的cpu_idle，最終需要要按照filed去累加，過大數據緩存累加，容易OOM，這個需要考慮storm的算子設計。

2.數據范圍的圈定是支持三層，也就是數據上卷操作如何來支持。

先來看第一個問題，介紹storm算子的設計，大家看下圖：

整個topology做到了無狀態，處理的數據是自包含，其次計算加了一層預處理bolt，先用shuffer來處理一層，降低field到聚合bolt的計算量。比如計算10w機器的10s 鐘cpu_idle(1wqps)先用10個預處理bolt，每個bolt就是只要累加1/10的數據，然后到下一層的計算量就會較小了。

算子可以這么設計是因為計算avg不受影響，avg=sum/count，把10s sum加起來，和先加2s的sum，然后2s中間結果再加起來，除以count，精度沒有損失，但分位值有精度損失，這個需要權衡。

storm算子設計就介紹到這，下面開始介紹數據上卷操作。

數據上卷在接入層做數據一維打平，在接入層的時候按照名字服務的圈定范圍變成了多份自包含數據，比如實例1=>服務2=>服務組3，那么來自實例1的數據就變成兩條數據。

這兩條數據一個范圍屬于服務2，一個屬于范圍服務組3，其他都一樣，也就是犧牲了計算資源，保證整個計算數據都是不相關的，這個其實是有優化空間的，大家可以自己考慮。

到這里多維度采集&計算基本功能點介紹完了。下面就介紹下穩定性的考慮了。

此處有圖：

前面一直強調數據符合28定律，所以這個系統首先要支持流控，支持按數據重要性做優先級處理，有如下措施：

第一，接入adaptor層，實現按產品線作為流控基本單元，和使用統計，誰用的多就必須多出銀子，通過設置黑白名單，當出現緊急情況下，降級處理。

第二，聚合計算做成整個無狀態，可水平擴展，多機房互備，因為kafka+storm不敢說是專家，所以在應用架構上做了些文章，主要為：

數據按照名字服務的范圍圈出來后，我們發現，只要保證圈出來的“同一范圍”的數據保證在同一個計算單元計算，就沒有任何問題。

比如建立兩個機房集群1，2，每個機房建立3個kafka topic/ storm計算單元，取名為A，B，C計算單元，通過adaptor，將接收的數據做映射，可以有如下映射：

比如地圖產品線的接入服務，命名為：map.nginx，只要范圍map.nginx的數據映射到一個計算單元即可，可以用如下規則：map.nginx接入 => 集群2，1計算單元A

這樣所有map的接入nginx數據就直接將數據寫入到集群2機房的A計算單元來完成，集群2的計算單元B掛了，當然不會影響map.nginx。

總結來說，整個計算都是無狀態，可水平擴展；支持流控，當有異常時，可以進行雙機房切換，如果有資源100%冗余，如果沒有，就選擇block一些產品線，服務降級。

到這里，整個多維度監控采集和計算介紹完成了：)下面說一下總結和展望吧！

采集就是一個標準化的過程，文本用命名正則其實是無奈之舉，期望是pb日志，這樣不會因為日志變動導致正則失效，而且性能也會提升；APM也是一樣，這個類似于lib的功能，不用通過日志能采到核心數據。

個人很看好pb日志，如果能夠有一個通用的pb模板，有一個pb日志的規范推得好，那么還是很有市場的，以后只要這么打日志，用這個模板的解析，就能得到很多內部的數據，不用寫正則。

采集就是一個標準之爭的權衡，估計你不會罵linus大神為啥把進程監控信息用文本放在/proc/pid/stat，而且進程名為啥只有16個字節；標準就在那，自己需要寫agent去將這個標準轉換為你內部的標準。

當你自己推出了監控標準，在公司內部用的很多的時候，RD/op需要努力的去適配你了，他們需要變換數據格式到監控標準上；所以，到底是誰多走一步，這個就需要看大家做監控的能力了:)

聚合計算的考慮則是各種算子的豐富，比如uv，還有就是二次計算，就是在storm計算的數據之上，再做一次計算；比如服務=>服務組的上卷操作可以通過二次計算來完成。

比如服務組包含了服務1、服務2，那么我們可以先只計算服務1、服務2的pv數據，然后通過二次計算，算出整個服務組的pv數據 ，由于二次計算沒有大數據壓力，可以做的支持更多的算子，靈活性，這個就不展開了。

我總結一下：

1.28定律，監控需要傾斜資源處理“關鍵”指標數據。

2.關鍵指標數據需要多維度觀察，1點變多點，這些數據是相互關聯，需要進行meta和配置管理。

3.系統設計時，數據模型先行，功能化、服務化、層次化、無狀態化。

4.對開源系統的態度，需要做適配，盡可能屏蔽開源細節，除了啃源碼之外，在整個應用架構上做文章，保證高可用性。

答疑環節

1.抓取數據的時候需要客戶端裝agent?必須要agent嗎?

從兩方面回答這個問題吧！首先系統設計的是層級化的，你可以不用agent，直接推送到我們的計算接入層；其次，如果你的數據需要采集，那么就是一個標準化的適配過程，比如你的監控數據以http端口暴露出來，那么也需要另一個人去這個http端口來取，手段不重要，重要的是你們兩個數據的轉換過程，所以不要糾結有沒有agent，這個事情誰做都需要做。

2.采集之后，日志是怎么處理的?

日志采集后，通過命名正則進行格式化，變成k:v對，然后將這些k:v對作為類似參數，直接填寫到多維度數據模型里面，然后發給聚合計算模塊處理。相當于對日志里面相同的字段進行統計，上面說的比如地圖nginx日志的處理就是這樣。

3.elesticsearch+logstash百度有木有在用呢?還有kafka在百度運維平臺中的使用是什么狀態呢?

ELK在小產品線有使用，這個多維度監控可以大部分的情況下替換ELK，而且說的自信點，我們重寫的agent性能快logstash十倍，而且符合我們的配置下發體系，整個運維元數據定義等；kafka在剛剛的系統里面就是和storm配合作為聚合計算的實現架構。

但我想強調的是，盡量屏蔽開源細節，在kafka+storm上面我們踩過不少坑。通過上面介紹的這種應用框架，可以保證很高的可靠性。

4.多維度數據監控在哪些場景會用的到，可以詳細說下幾個案例嗎?

我今天講的是多維度數據監控的采集和計算，沒有去講這個應用，但可以透露一下，我們現在的智能監控體系都是在剛剛講的這一套采集&計算架構之上；每層都各司其職，計算完成后，交給展示/分析一個好的數據模型，至于在這個模型上，你可以做根因定位，做同環比監控，這個我就不展開了。

5.能介紹百度監控相關的數量級嗎?

這個就不透露了，但大家也都知道BAT三家的機器規模了，而且在百度運維平臺開發部門，我們的平臺是針對百度所有產品線；所以，有志于做大規模數據分析處理的同學，你肯定不會失望(又是一個硬廣：)

6.不同產品線的聚合計算規則是怎么管理的。不同聚合規則就對應這不同的bolt甚至topology，怎么在storm開發中協調這個問題?

看到一個比較好的問題，首先我們設計的時候，是通用聚合計算，就計算sum/count/avg/min/max分位值，常見的運維都可以涵蓋；我們通過agent做了公式計算，表達能力也足夠了，同時有二次計算。不一定非要在storm層解決。

我提倡“正確的位置解決問題”，當然大家對這個正確位置理解不同。

　　7.topology無狀態這句話沒太明白。storm topology的狀態管理不是自身nimbus控制的嗎?百度的應用架構在此做了哪些工作或者設計?

我說的是寫的storm算子是無狀態的，整個數據都是自包含的，我們在應用架構上，就是控制發給stormtopology的數據；多機房互備等；我說的應用架構師在這個storm之上的架構。相當于我認為整個storm topology是我接入adaptor層的調度單元。

【編輯推薦】