百度多維度數據監控采集和聚合計算的運維實踐分享

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

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

1.監控目標和挑戰

2.多維度數據監控

2.1.采集的設計和挑戰

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

2.3.高可用性保障設計

3.總結&展望

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

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

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

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

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

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

1.監控指標多，報警多

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

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

進入正題：

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

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

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

1. 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：

1. "dict" : [   
2. "CHINANET => 電信" ,   
3. "UNICOM => 聯通" ,   
4. "CMNET => 移動" ,   
5. "CRTC => 鐵通"    
6. ]