今天一大早就看到了一篇文章宿百，叫【大數(shù)據(jù)對于運維的意義】。該文章基本上是從三個層面闡述的：

1. 工程數(shù)據(jù)洪添，譬如工單數(shù)量垦页，SLA可用性，基礎(chǔ)資源干奢，故障率痊焊，報警統(tǒng)計
2. 業(yè)務(wù)數(shù)據(jù)，譬如業(yè)務(wù)DashBoard,Trace調(diào)用鏈忿峻，業(yè)務(wù)拓?fù)淝袚Q薄啥，業(yè)務(wù)指標(biāo)，業(yè)務(wù)基準(zhǔn)數(shù)據(jù)逛尚，業(yè)務(wù)日志挖掘
3. 數(shù)據(jù)可視化

當(dāng)然垄惧，這篇文章談的是運維都有哪些數(shù)據(jù)，哪些指標(biāo)绰寞，以及數(shù)據(jù)呈現(xiàn)到逊。并沒有談及如何和大數(shù)據(jù)相關(guān)的架構(gòu)做整合，從而能讓這些數(shù)據(jù)真的變得活起來滤钱。

比較湊巧的是觉壶，原先百度的桑文峰的分享也講到日志的多維度分析，吃完飯的時候件缸，一位優(yōu)酷的朋友也和我探討了關(guān)于業(yè)務(wù)監(jiān)控的的問題铜靶。而我之前發(fā)表在肉餅鋪子里的一篇文章【大數(shù)據(jù)給公司帶來了什么】 也特地提到了大數(shù)據(jù)對于整個運維的幫助，當(dāng)時因為這篇內(nèi)容的主旨是羅列大數(shù)據(jù)的用處他炊，自然沒法細(xì)講運維和大數(shù)據(jù)的整合這一塊争剿。

上面的文字算引子，在步入正式的探討前佑稠，有一點我覺得值得強調(diào)：

雖然這里講的是如何將大數(shù)據(jù)思維/架構(gòu)應(yīng)用于運維秒梅，平臺化運維工作旗芬，但是和大數(shù)據(jù)本質(zhì)上沒有關(guān)系舌胶，我們只是將大數(shù)據(jù)處理的方式和思想應(yīng)用在運維工作上。所以疮丛，即使你現(xiàn)在所在的公司沒有數(shù)據(jù)團隊支撐幔嫂，也是完全可以通過現(xiàn)有團隊完成這件事情的辆它。

運維監(jiān)控現(xiàn)狀

很多公司的運維的監(jiān)控具有如下特質(zhì)：

1. 只能監(jiān)控基礎(chǔ)運維層次，通過zabbit等工具提供服務(wù)器,CPU,內(nèi)存等相關(guān)的監(jiān)控履恩。這部分重要锰茉，但確實不是運維的核心。
2. 對業(yè)務(wù)的監(jiān)控是最復(fù)雜的切心，而現(xiàn)在很多公司的要么還處于Shell腳本的刀耕火種階段飒筑，要么開發(fā)能力較強，但是還是東一榔頭西一棒子绽昏，不同的業(yè)務(wù)需要不同的監(jiān)控系統(tǒng)协屡，人人都可以根據(jù)的自己的想法開發(fā)一個監(jiān)控的工具也好，系統(tǒng)也好全谤，平臺也好肤晓。總之是比較凌亂的认然。
3. 使用第三方的監(jiān)控平臺补憾。這個似乎在Rails/NodeJS/Pythone相關(guān)語系開發(fā)的產(chǎn)品中比較常見。我不做過多評價卷员，使用后冷暖自知盈匾。

當(dāng)然也有抽象的很好的，比如點評網(wǎng)的運維監(jiān)控?fù)?jù)說就做的相當(dāng)好毕骡，運維很閑威酒，天天沒事就根據(jù)自己的監(jiān)控找開發(fā)的搽，讓開發(fā)持續(xù)改進挺峡。不過他們的指導(dǎo)思想主要有兩個：

1. 運維自動化葵孤。怎么能夠?qū)崿F(xiàn)這個目標(biāo)就怎么搞，這嚴(yán)重依賴于搞的人的規(guī)劃能力和經(jīng)驗橱赠。
2. 抽象化尤仍，根據(jù)實際面臨的問題做出抽象，得到對應(yīng)的系統(tǒng)狭姨，比如需要發(fā)布宰啦，于是又發(fā)布系統(tǒng)，需要管理配置文件饼拍，所以有配管系統(tǒng)赡模，需要日志分析所以有了有日志分析系統(tǒng)。然而這樣是比較零散的师抄。

有點扯遠漓柑，我們還是focus在監(jiān)控上。

如果以大數(shù)據(jù)的思維去思考，我們應(yīng)該如何做好監(jiān)控這件事情辆布？

羅列出你的數(shù)據(jù)源

【大數(shù)據(jù)對于運維的意義】 這篇文章也講了瞬矩，主要有工程數(shù)據(jù)，業(yè)務(wù)數(shù)據(jù)锋玲。所有的數(shù)據(jù)源都有一個共性景用，就是日志。無論文本的也好惭蹂，二進制的也好伞插。所以日志是整個信息的源頭。日志包含的信息足以讓我們追查到下面幾件事情：

• 系統(tǒng)健康狀況監(jiān)控
• 查找故障根源
• 系統(tǒng)瓶頸診斷和調(diào)優(yōu)
• 追蹤安全相關(guān)問題

從日志我們可以挖掘出什么盾碗？

我覺得抽象起來就一個： 指標(biāo)蜂怎。
指標(biāo)可以再進行分類，

1. 業(yè)務(wù)層面置尔，如團購業(yè)務(wù)每秒訪問數(shù)杠步，團購券每秒驗券數(shù)，每分鐘支付榜轿、創(chuàng)建訂單等

2. 應(yīng)用層面幽歼，每個應(yīng)用的錯誤數(shù)，調(diào)用過程谬盐，訪問的平均耗時甸私，最大耗時，95線等

3. 系統(tǒng)資源層面：如cpu飞傀、內(nèi)存皇型、swap、磁盤砸烦、load弃鸦、主進程存活等

4. 網(wǎng)絡(luò)層面： 如丟包、ping存活幢痘、流量唬格、tcp連接數(shù)等

每個分類里的每個小點其實都是一個指標(biāo)。

如何統(tǒng)一實現(xiàn)

千萬不要針對具體問題進行解決颜说，大數(shù)據(jù)架構(gòu)上的一個思維就是：我能夠提供一個平臺讓大家方便解決這些問題么购岗？ 而不是，這個問題我能解決么门粪？

先來看看架構(gòu)圖：

log-collect.png

因為目前我負(fù)責(zé)應(yīng)用層的研發(fā)喊积，業(yè)務(wù)還比較少，主要就需要監(jiān)控三個系統(tǒng)：

1. 推薦
2. 搜索
3. 統(tǒng)一查詢引擎

所以監(jiān)控的架構(gòu)設(shè)計略簡單些玄妈。如果你希望進行日志存儲以及事后批量分析乾吻，則可以采用淘寶的這套架構(gòu)方式：

log-collect2.png

稍微說明下髓梅，日志收集Agent可以使用Flume,鷹眼Storm集群，其實就是Storm集群溶弟，當(dāng)然有可能是淘寶內(nèi)部Java版的女淑，
Storm(或第一幅圖的SparkStreaming)做兩件事情

1. 將日志過濾瞭郑，格式化辜御，或存儲起來
2. 進行實時計算，將指標(biāo)數(shù)據(jù)存儲到HBase里去

到目前為止屈张，我們沒有做任何的開發(fā)擒权，全部使用大數(shù)據(jù)里通用的一些組件。至于這些組件需要多少服務(wù)器阁谆，就看對應(yīng)的日志量規(guī)模了碳抄，三五臺到幾百臺都是可以的。

需要開發(fā)的地方只有兩個點场绿，有一個是一次性的剖效，有一個則是長期。

先說說一次性的焰盗，其實就是大盤展示系統(tǒng)璧尸。這個就是從HBase里取出數(shù)據(jù)做展示。這個貌似也有開源的一套熬拒，ELK爷光。不過底層不是用的HBase存儲，而是ES澎粟。這里就不詳細(xì)討論蛀序。

長期的則是SparkStreaming(淘寶是使用Storm，我建議用SparkStreaming,因為SparkStreaming可以按時間窗口活烙，也可以按量統(tǒng)一做計算)徐裸，這里你需要定義日志的處理邏輯，生成我上面提到的各項指標(biāo)啸盏。

這里有一個什么好處呢倦逐，就是平臺化了，對新的監(jiān)控需求響應(yīng)更快了宫补，開發(fā)到上線可能只要幾個小時的功夫檬姥。如果某個系統(tǒng)某天需要一個新的監(jiān)控指標(biāo)，我們只要開發(fā)個SparkStreaming程序粉怕，丟到平臺里去健民，這事就算完了。

第一幅圖的平臺我是已經(jīng)實現(xiàn)了的贫贝。我目前在SparkStreaming上只做了三個方面比較基礎(chǔ)的監(jiān)控秉犹，不過應(yīng)該夠用了蛉谜。

1. 狀態(tài)碼大盤。HTTP響應(yīng)碼的URL(去掉query參數(shù))排行榜崇堵。比如你打開頁面就可以看到發(fā)生500錯誤的top100的URL型诚，以及該URL所歸屬的系統(tǒng)。
2. 響應(yīng)耗時大盤鸳劳。URL請求耗時排行榜狰贯。比如你打開頁面就可以看到5分鐘內(nèi)平均響應(yīng)耗時top100的URL(去掉query參數(shù)).
3. 還有就是Trace系統(tǒng)。類似Google的Dapper,淘寶的EagleEye赏廓。給出一個唯一的UUID,可以追蹤到特定一個Request的請求鏈路涵紊。每個依賴服務(wù)的響應(yīng)情況，比如響應(yīng)時間幔摸。對于一個由幾個甚至幾百個服務(wù)組成的大系統(tǒng)摸柄，意義非常大，可以方便的定位出到底是那個系統(tǒng)的哪個API的問題既忆。這個最大的難點是需要統(tǒng)一底層的RPC/HTTP調(diào)用框架驱负，進行埋點。因為我使用的是自研的ServiceFramework框架患雇，通訊埋點就比較簡單跃脊。如果是在一個業(yè)務(wù)線復(fù)雜，各個系統(tǒng)使用不同技術(shù)開發(fā)庆亡，想要做這塊就要做好心理準(zhǔn)備了匾乓。

現(xiàn)在，如果你想要監(jiān)控一個系統(tǒng)是不是存活又谋，你不在需要取寫腳本去找他的pid看進程是不是存在拼缝，系統(tǒng)發(fā)現(xiàn)在一定的周期內(nèi)沒有日志，就可以認(rèn)為它死了彰亥。而系統(tǒng)如果有異常咧七，比如有大量的慢查詢，大盤一定能展示出來任斋。

描述到這继阻，我們可以看到，這套架構(gòu)的優(yōu)勢在哪：

1. 基本上沒有需要自己開發(fā)的系統(tǒng)废酷。從日志收集瘟檩，到日志存儲，到結(jié)果存儲等澈蟆，統(tǒng)統(tǒng)都是現(xiàn)成的組件墨辛。
2. 可擴展性好。每個組件都是集群模式的趴俘，沒有單點故障睹簇。每個組件都是可水平擴展的奏赘，日志量大了，加機器就好太惠。
3. 開發(fā)更集中了磨淌。你只要關(guān)注日志實際的分析處理，提煉指標(biāo)即可凿渊。

大數(shù)據(jù)思維

對于運維的監(jiān)控梁只，利用大數(shù)據(jù)思維，需要分三步走：

1. 找到數(shù)據(jù)
2. 分析定義從數(shù)據(jù)里中我能得到什么
3. 從大數(shù)據(jù)平臺中挑選你要的組件完成搭積木式開發(fā)

所有系統(tǒng)最可靠的就是日志輸出嗽元，系統(tǒng)是不是正常敛纲，發(fā)生了什么情況喂击，我們以前是出了問題去查日志剂癌，或者自己寫個腳本定時去分析。現(xiàn)在這些事情都可以整合到一個已有的平臺上翰绊，我們唯一要做的就是定義處理日志的的邏輯佩谷。

這里有幾點注意的：

1. 如果你擁有復(fù)雜的產(chǎn)品線，那么日志格式會是一個很痛苦的事情监嗜。以為這中間Storm(或者SparkStreaming)的處理環(huán)節(jié)你需要做大量的兼容適配谐檀。我個人的意見是，第一裁奇，沒有其他更好的辦理桐猬，去兼容適配吧，第二刽肠，推動大家統(tǒng)一日志格式溃肪。兩件事情一起做。我一個月做不完音五，那我用兩年時間行么惫撰？總有一天大家都會有統(tǒng)一的日志格式的。
2. 如果你的研發(fā)能力有富余,或者有大數(shù)據(jù)團隊支撐躺涝，那么可以將進入到SparkStreaming中的數(shù)據(jù)存儲起來厨钻，然后通過SparkSQL等做即席查詢。這樣坚嗜，有的時候原先沒有考慮的指標(biāo)夯膀，你可以直接基于日志做多維度分析。分析完了苍蔬，你覺得好了诱建，需要固化下來，那再去更新你的SparkStreaming程序银室。

后話

我做上面第一幅圖架構(gòu)實現(xiàn)時涂佃，從搭建到完成SparkStreaming程序開發(fā)励翼，到數(shù)據(jù)最后進入HBase存儲，大概只花了一天多的時間辜荠。當(dāng)然為了完成那個Trace的指標(biāo)分析汽抚，我修改ServiceFramework框架大約改了兩三天。因為Trace分析確實比較復(fù)雜伯病。當(dāng)然還有一個比較消耗工作量的造烁，是頁面可視化，我這塊自己還沒有能力做午笛，等招個Web開發(fā)工程師再說了惭蟋。