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

1. 工程數據，譬如工單數量，SLA可用性，基礎資源，故障率，報警統計

2. 業務數據，譬如業務DashBoard,Trace調用鏈，業務拓撲切換，業務指標，業務基準數據，業務日志挖掘

3. 數據可視化

當然，這篇文章談的是運維都有哪些數據，哪些指標，以及數據呈現。并沒有談及如何和大數據相關的架構做整合，從而能讓這些數據真的變得活起來。

比較湊巧的是，原先百度的桑文峰的分享也講到日志的多維度分析，吃完飯的時候，一位優酷的朋友也和我探討了關于業務監控的的問題。而我之前發表在肉餅鋪子里的一篇文章【大數據給公司帶來了什么】 也特地提到了大數據對于整個運維的幫助，當時因為這篇內容的主旨是羅列大數據的用處，自然沒法細講運維和大數據的整合這一塊。

上面的文字算引子，在步入正式的探討前，有一點我覺得值得強調：

雖然這里講的是如何將大數據思維/架構應用于運維，平臺化運維工作，但是和大數據本質上沒有關系，我們只是將大數據處理的方式和思想應用在運維工作上。所以，即使你現在所在的公司沒有數據團隊支撐，也是完全可以通過現有團隊完成這件事情的。

很多公司的運維的監控具有如下特質：

1. 只能監控基礎運維層次，通過zabbit等工具提供服務器,CPU,內存等相關的監控。這部分重要，但確實不是運維的核心。

2. 對業務的監控是最復雜的，而現在很多公司的要么還處于Shell腳本的刀耕火種階段，要么開發能力較強，但是還是東一榔頭西一棒子，不同的業務需要不同的監控系統，人人都可以根據的自己的想法開發一個監控的工具也好，系統也好，平臺也好。總之是比較凌亂的。

3. 使用第三方的監控平臺。這個似乎在Rails/NodeJS/Pythone相關語系開發的產品中比較常見。我不做過多評價，使用后冷暖自知。

當然也有抽象的很好的，比如點評網的運維監控據說就做的相當好，運維很閑，天天沒事就根據自己的監控找開發的搽，讓開發持續改進。不過他們的指導思想主要有兩個：

1. 運維自動化。怎么能夠實現這個目標就怎么搞，這嚴重依賴于搞的人的規劃能力和經驗。

2. 抽象化，根據實際面臨的問題做出抽象，得到對應的系統，比如需要發布，于是又發布系統，需要管理配置文件，所以有配管系統，需要日志分析所以有了有日志分析系統。然而這樣是比較零散的。

有點扯遠，我們還是focus在監控上。

如果以大數據的思維去思考，我們應該如何做好監控這件事情？

【大數據對于運維的意義】 這篇文章也講了，主要有工程數據，業務數據。所有的數據源都有一個共性，就是日志。無論文本的也好，二進制的也好。所以日志是整個信息的源頭。日志包含的信息足以讓我們追查到下面幾件事情：

• 系統健康狀況監控

• 查找故障根源

• 系統瓶頸診斷和調優

• 追蹤安全相關問題

我覺得抽象起來就一個： 指標。

指標可以再進行分類，

1. 業務層面，如團購業務每秒訪問數，團購券每秒驗券數，每分鐘支付、創建訂單等

2. 應用層面，每個應用的錯誤數，調用過程，訪問的平均耗時，最大耗時，95線等

3. 系統資源層面：如cpu、內存、swap、磁盤、load、主進程存活等

4. 網絡層面： 如丟包、ping存活、流量、tcp連接數等

每個分類里的每個小點其實都是一個指標。

千萬不要針對具體問題進行解決，大數據架構上的一個思維就是：我能夠提供一個平臺讓大家方便解決這些問題么？ 而不是，這個問題我能解決么？

先來看看架構圖：

log-collect.png

因為目前我負責應用層的研發，業務還比較少，主要就需要監控三個系統：

1. 推薦

2. 搜索

3. 統一查詢引擎

所以監控的架構設計略簡單些。如果你希望進行日志存儲以及事后批量分析，則可以采用淘寶的這套架構方式：

稍微說明下，日志收集Agent可以使用Flume,鷹眼Storm集群，其實就是Storm集群，當然有可能是淘寶內部Java版的，

Storm(或第一幅圖的SparkStreaming)做兩件事情

1. 將日志過濾，格式化，或存儲起來

2. 進行實時計算，將指標數據存儲到HBase里去

到目前為止，我們沒有做任何的開發，全部使用大數據里通用的一些組件。至于這些組件需要多少服務器，就看對應的日志量規模了，三五臺到幾百臺都是可以的。

需要開發的地方只有兩個點，有一個是一次性的，有一個則是長期。

先說說一次性的，其實就是大盤展示系統。這個就是從HBase里取出數據做展示。這個貌似也有開源的一套，ELK。不過底層不是用的HBase存儲，而是ES。這里就不詳細討論。

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

這里有一個什么好處呢，就是平臺化了，對新的監控需求響應更快了，開發到上線可能只要幾個小時的功夫。如果某個系統某天需要一個新的監控指標，我們只要開發個SparkStreaming程序，丟到平臺里去，這事就算完了。

第一幅圖的平臺我是已經實現了的。我目前在SparkStreaming上只做了三個方面比較基礎的監控，不過應該夠用了。

1. 狀態碼大盤。HTTP響應碼的URL(去掉query參數)排行榜。比如你打開頁面就可以看到發生500錯誤的top100的URL，以及該URL所歸屬的系統。

2. 響應耗時大盤。URL請求耗時排行榜。比如你打開頁面就可以看到5分鐘內平均響應耗時top100的URL(去掉query參數).

3. 還有就是Trace系統。類似Google的Dapper,淘寶的EagleEye。給出一個唯一的UUID,可以追蹤到特定一個Request的請求鏈路。每個依賴服務的響應情況，比如響應時間。對于一個由幾個甚至幾百個服務組成的大系統，意義非常大，可以方便的定位出到底是那個系統的哪個API的問題。這個最大的難點是需要統一底層的RPC/HTTP調用框架，進行埋點。因為我使用的是自研的ServiceFramework框架，通訊埋點就比較簡單。如果是在一個業務線復雜，各個系統使用不同技術開發，想要做這塊就要做好心理準備了。

現在，如果你想要監控一個系統是不是存活，你不在需要取寫腳本去找他的pid看進程是不是存在，系統發現在一定的周期內沒有日志，就可以認為它死了。而系統如果有異常，比如有大量的慢查詢，大盤一定能展示出來。

描述到這，我們可以看到，這套架構的優勢在哪：

1. 基本上沒有需要自己開發的系統。從日志收集，到日志存儲，到結果存儲等，統統都是現成的組件。

2. 可擴展性好。每個組件都是集群模式的，沒有單點故障。每個組件都是可水平擴展的，日志量大了，加機器就好。

3. 開發更集中了。你只要關注日志實際的分析處理，提煉指標即可。

對于運維的監控，利用大數據思維，需要分三步走：

1. 找到數據

2. 分析定義從數據里中我能得到什么

3. 從大數據平臺中挑選你要的組件完成搭積木式開發

所有系統最可靠的就是日志輸出，系統是不是正常，發生了什么情況，我們以前是出了問題去查日志，或者自己寫個腳本定時去分析。現在這些事情都可以整合到一個已有的平臺上，我們唯一要做的就是定義處理日志的的邏輯。

這里有幾點注意的：

1. 如果你擁有復雜的產品線，那么日志格式會是一個很痛苦的事情。以為這中間Storm(或者SparkStreaming)的處理環節你需要做大量的兼容適配。我個人的意見是，第一，沒有其他更好的辦理，去兼容適配吧，第二，推動大家統一日志格式。兩件事情一起做。我一個月做不完，那我用兩年時間行么？總有一天大家都會有統一的日志格式的。

2. 如果你的研發能力有富余,或者有大數據團隊支撐，那么可以將進入到SparkStreaming中的數據存儲起來，然后通過SparkSQL等做即席查詢。這樣，有的時候原先沒有考慮的指標，你可以直接基于日志做多維度分析。分析完了，你覺得好了，需要固化下來，那再去更新你的SparkStreaming程序。

我做上面第一幅圖架構實現時，從搭建到完成SparkStreaming程序開發，到數據最后進入HBase存儲，大概只花了一天多的時間。

當然為了完成那個Trace的指標分析，我修改ServiceFramework框架大約改了兩三天。因為Trace分析確實比較復雜。當然還有一個比較消耗工作量的，是頁面可視化，我這塊自己還沒有能力做，等招個Web開發工程師再說了。

作者：祝威廉
來源：http://www.jianshu.com/p/f634d7fc0f05

————廣告時間————

《馬哥Linux云計算及架構師》課程，由知名Linux布道師馬哥創立，經歷了8年的發展，聯合阿里巴巴、唯品會、大眾點評、騰訊、陸金所等大型互聯網一線公司的馬哥課程團隊的工程師進行深度定制開發，課程采用 Centos7.2系統教學，加入了大量實戰案例，授課案例均來自于一線的技術案例。

開課時間：11月06號

掃描二維碼和更多小伙伴組團學習