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

下面以百度地圖產(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 

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

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

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

總結(jié)一下，“關(guān)鍵”指標(biāo)數(shù)據(jù)需要多角度/多維度觀察，會一點變多點，這些多點數(shù)據(jù)有關(guān)聯(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)控項間無關(guān)聯(lián)，除非對名字做一系列規(guī)定，并增加對名字做split操作之類，否則很難讓上面兩個數(shù)據(jù)產(chǎn)生關(guān)聯(lián)；而且配置的個數(shù)是維度的笛卡爾積。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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