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

　　現(xiàn)在開始本次分享，本次分享的主題是《多維度數(shù)據(jù)監(jiān)控采集&計算》，提綱如下，分為3個部分：

　　1.監(jiān)控目標和挑戰(zhàn)

　　2.多維度數(shù)據(jù)監(jiān)控

　　2.1.采集的設計和挑戰(zhàn)

　　2.2.聚合計算的設計和挑戰(zhàn)

　　2.3.高可用性保障設計

　　3.總結&展望

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

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

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

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

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

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

　　1.監(jiān)控指標多，報警多

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

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

　　進入正題：

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

#p#

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

　　下面以百度地圖產(chǎn)品線接入日志為例 (典型的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 

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

　　可以看到，一個指標會變?yōu)槎鄠€指標，比如pv監(jiān)控項按照 5大運營商*36個省份 * 5個機房將產(chǎn)生900個指標數(shù)據(jù)，人工管理這種配置很困難，而且如果新增機房，需要新增配置5*36=180個配置，這個就不是人干的了。

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

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

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

　　貼一下圖：

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

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

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

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

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

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

　　鋪墊了這么長，現(xiàn)在看看“多維度數(shù)據(jù)監(jiān)控”的框架拆解：

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

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

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

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

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

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

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

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

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

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

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

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

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

"dict": [  
"CHINANET => 電信",  
"UNICOM => 聯(lián)通",  
"CMNET => 移動",  
"CRTC => 鐵通"  
] 

　　#p#

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

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

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

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

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

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

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

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

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

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

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

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

　　前面提到，多維度數(shù)據(jù)監(jiān)控不關注“單機”數(shù)據(jù)，只關注聚合數(shù)據(jù)，那首先***個問題，怎么圈定“聚合"范圍?這塊功能在名字服務中實現(xiàn)，名字服務不展開。

[[153583]]

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

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

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

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

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

　　遇到的挑戰(zhàn)包括：

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

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

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

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

#p#

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

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

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

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

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

　　此處有圖：

　　前面一直強調數(shù)據(jù)符合28定律，所以這個系統(tǒng)首先要支持流控，支持按數(shù)據(jù)重要性做優(yōu)先級處理，有如下措施：

　　***，接入adaptor層，實現(xiàn)按產(chǎn)品線作為流控基本單元，和使用統(tǒng)計，誰用的多就必須多出銀子，通過設置黑白名單，當出現(xiàn)緊急情況下，降級處理。

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

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

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

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

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

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

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

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

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

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

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

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

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

　　我總結一下：

　　1.28定律，監(jiān)控需要傾斜資源處理“關鍵”指標數(shù)據(jù)。

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

3.系統(tǒng)設計時，數(shù)據(jù)模型先行，功能化、服務化、層次化、無狀態(tài)化。

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

　　答疑環(huán)節(jié)

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

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

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

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

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

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

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

　　4.多維度數(shù)據(jù)監(jiān)控在哪些場景會用的到，可以詳細說下幾個案例嗎?

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

　　5.能介紹百度監(jiān)控相關的數(shù)量級嗎?

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

　　6.不同產(chǎn)品線的聚合計算規(guī)則是怎么管理的。不同聚合規(guī)則就對應這不同的bolt甚至topology，怎么在storm開發(fā)中協(xié)調這個問題?

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

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

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

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