用大數(shù)據(jù)思維做運維監(jiān)控是怎樣一種體驗?
工程數(shù)據(jù)，譬如工單數(shù)量，SLA可用性，基礎資源，故障率，報警統(tǒng)計
業(yè)務數(shù)據(jù)，譬如業(yè)務DashBOArd，Trace調(diào)用鏈，業(yè)務拓撲切換，業(yè)務指標，業(yè)務基準數(shù)據(jù)，業(yè)務日志挖掘
數(shù)據(jù)可視化
當然，這篇文章談的是運維都有哪些數(shù)據(jù)，哪些指標，以及數(shù)據(jù)呈現(xiàn)。并沒有談及如何和大數(shù)據(jù)相關的架構做整合，從而能讓這些數(shù)據(jù)真的變得活起來。
比較湊巧的是，原先百度的桑文峰的分享也講到日志的多維度分析，吃完飯的時候，一位優(yōu)酷的朋友也和我探討了關于業(yè)務監(jiān)控的的問題。而我之前發(fā)表在肉餅鋪子里的一篇文章《大數(shù)據(jù)給公司帶來了什么》也特地提到了大數(shù)據(jù)對于整個運維的幫助，當時因為這篇內(nèi)容的主旨是羅列大數(shù)據(jù)的用處，自然沒法細講運維和大數(shù)據(jù)的整合這一塊。
上面的文字算引子，在步入正式的探討前，有一點我覺得值得強調(diào)：
雖然這里講的是如何將大數(shù)據(jù)思維/架構應用于運維，平臺化運維工作，但是和大數(shù)據(jù)本質(zhì)上沒有關系，我們只是將大數(shù)據(jù)處理的方式和思想應用在運維工作上。所以，即使你現(xiàn)在所在的公司沒有數(shù)據(jù)團隊支撐，也是完全可以通過現(xiàn)有團隊完成這件事情的。
1、運維監(jiān)控現(xiàn)狀
很多公司的運維的監(jiān)控具有如下特質(zhì)：
只能監(jiān)控基礎運維層次，通過zabbit等工具提供服務器，CPU，內(nèi)存等相關的監(jiān)控。這部分重要，但確實不是運維的核心。
對業(yè)務的監(jiān)控是最復雜的，而現(xiàn)在很多公司的要么還處于Shell腳本的刀耕火種階段，要么開發(fā)能力較強，但是還是東一榔頭西一棒子，不同的業(yè)務需要不同的監(jiān)控系統(tǒng)，人人都可以根據(jù)的自己的想法開發(fā)一個監(jiān)控的工具也好，系統(tǒng)也好，平臺也好。總之是比較凌亂的。
使用第三方的監(jiān)控平臺。這個似乎在Rails/NodeJS/Pythone相關語系開發(fā)的產(chǎn)品中比較常見。我不做過多評價，使用后冷暖自知。
當然也有抽象得很好的，比如點評網(wǎng)的運維監(jiān)控據(jù)說就做得相當好，運維很閑，天天沒事就根據(jù)自己的監(jiān)控找開發(fā)的茬，讓開發(fā)持續(xù)改進。不過他們的指導思想主要有兩個：
運維自動化。怎么能夠實現(xiàn)這個目標就怎么搞，這嚴重依賴于搞的人的規(guī)劃能力和經(jīng)驗。
抽象化，根據(jù)實際面臨的問題做出抽象，得到對應的系統(tǒng)，比如需要發(fā)布，于是又發(fā)布系統(tǒng)，需要管理配置文件，所以有配管系統(tǒng)，需要日志分析所以有了有日志分析系統(tǒng)。然而這樣是比較零散的。
有點扯遠，我們還是focus在監(jiān)控上。
如果以大數(shù)據(jù)的思維去思考，我們應該如何做好監(jiān)控這件事情?
2、羅列出你的數(shù)據(jù)源
《大數(shù)據(jù)對于運維的意義》這篇文章也講了，主要有工程數(shù)據(jù)，業(yè)務數(shù)據(jù)。所有的數(shù)據(jù)源都有一個共性，就是日志。無論文本的也好，二進制的也好。所以日志是整個信息的源頭。日志包含的信息足以讓我們追查到下面幾件事情：
系統(tǒng)健康狀況監(jiān)控
查找故障根源
系統(tǒng)瓶頸診斷和調(diào)優(yōu)
追蹤安全相關問題
從日志我們可以挖掘出什么?
我覺得抽象起來就一個：指標。
指標可以再進行分類：
業(yè)務層面，如團購業(yè)務每秒訪問數(shù)，團購券每秒驗券數(shù)，每分鐘支付、創(chuàng)建訂單等
應用層面，每個應用的錯誤數(shù)，調(diào)用過程，訪問的平均耗時，最大耗時，95線等
系統(tǒng)資源層面：如cpu、內(nèi)存、swap、磁盤、load、主進程存活等
網(wǎng)絡層面：如丟包、ping存活、流量、tcp連接數(shù)等
每個分類里的每個小點其實都是一個指標。
3、如何統(tǒng)一實現(xiàn)
千萬不要針對具體問題進行解決，大數(shù)據(jù)架構上的一個思維就是：我能夠提供一個平臺讓大家方便解決這些問題么?而不是，這個問題我能解決么?
先來看看架構圖：
圖1 大數(shù)據(jù)架構圖
因為目前我負責應用層的研發(fā)，業(yè)務還比較少，主要就需要監(jiān)控三個系統(tǒng)：
推薦
搜索
統(tǒng)一查詢引擎
所以監(jiān)控的架構設計略簡單些。如果你希望進行日志存儲以及事后批量分析，則可以采用淘寶的這套架構方式：
圖2 淘寶的架構方式
稍微說明下，日志收集Agent可以使用Flume，鷹眼Storm集群，其實就是Storm集群，當然有可能是淘寶內(nèi)部Java版的，Storm(或第一幅圖的SparkStreaming)做兩件事情。
將日志過濾，格式化，或存儲起來
進行實時計算，將指標數(shù)據(jù)存儲到HBase里去
到目前為止，我們沒有做任何的開發(fā)，全部使用大數(shù)據(jù)里通用的一些組件。至于這些組件需要多少服務器，就看對應的日志量規(guī)模了，三五臺到幾百臺都是可以的。
需要開發(fā)的地方只有兩個點，有一個是一次性的，有一個則是長期。
先說說一次性的，其實就是大盤展示系統(tǒng)。這個就是從HBase里取出數(shù)據(jù)做展示。這個貌似也有開源的一套，ELK。不過底層不是用的HBase存儲，而是ES。這里就不詳細討論。
長期的則是SparkStreaming(淘寶是使用Storm，我建議用SparkStreaming，因為SparkStreaming可以按時間窗口，也可以按量統(tǒng)一做計算)，這里你需要定義日志的處理邏輯，生成我上面提到的各項指標。
這里有一個什么好處呢，就是平臺化了，對新的監(jiān)控需求響應更快了，開發(fā)到上線可能只要幾個小時的功夫。如果某個系統(tǒng)某天需要一個新的監(jiān)控指標，我們只要開發(fā)個SparkStreaming程序，丟到平臺里去，這事就算完了。
第一幅圖的平臺我是已經(jīng)實現(xiàn)了的。我目前在SparkStreaming上只做了三個方面比較基礎的監(jiān)控，不過應該夠用了。
狀態(tài)碼大盤。HTTP響應碼的URL(去掉query參數(shù))排行榜。比如你打開頁面就可以看到發(fā)生500錯誤的top100的URL，以及該URL所歸屬的系統(tǒng)。
響應耗時大盤。URL請求耗時排行榜。比如你打開頁面就可以看到5分鐘內(nèi)平均響應耗時top100的URL(去掉query參數(shù))。
還有就是Trace系統(tǒng)。類似Google的Dapper，淘寶的EagleEye。給出一個唯一的UUID，可以追蹤到特定一個Request的請求鏈路。每個依賴服務的響應情況，比如響應時間。對于一個由幾個甚至幾百個服務組成的大系統(tǒng)，意義非常大，可以方便的定位出到底是那個系統(tǒng)的哪個API的問題。這個最大的難點是需要統(tǒng)一底層的RPC/HTTP調(diào)用框架，進行埋點。因為我使用的是自研的ServiceFramework框架，通訊埋點就比較簡單。如果是在一個業(yè)務線復雜，各個系統(tǒng)使用不同技術開發(fā)，想要做這塊就要做好心理準備了。
現(xiàn)在，如果你想要監(jiān)控一個系統(tǒng)是不是存活，你不在需要取寫腳本去找他的pid看進程是不是存在，系統(tǒng)發(fā)現(xiàn)在一定的周期內(nèi)沒有日志，就可以認為它死了。而系統(tǒng)如果有異常，比如有大量的慢查詢，大盤一定能展示出來。
描述到這，我們可以看到，這套架構的優(yōu)勢在哪：
基本上沒有需要自己開發(fā)的系統(tǒng)。從日志收集，到日志存儲，到結果存儲等，統(tǒng)統(tǒng)都是現(xiàn)成的組件。
可擴展性好。每個組件都是集群模式的，沒有單點故障。每個組件都是可水平擴展的，日志量大了，加機器就好。
開發(fā)更集中了。你只要關注日志實際的分析處理，提煉指標即可。
4、大數(shù)據(jù)思維
對于運維的監(jiān)控，利用大數(shù)據(jù)思維，需要分三步走：
找到數(shù)據(jù)
分析定義從數(shù)據(jù)里中我能得到什么
從大數(shù)據(jù)平臺中挑選你要的組件完成搭積木式開發(fā)
所有系統(tǒng)最可靠的就是日志輸出，系統(tǒng)是不是正常，發(fā)生了什么情況，我們以前是出了問題去查日志，或者自己寫個腳本定時去分析�，F(xiàn)在這些事情都可以整合到一個已有的平臺上，我們唯一要做的就是定義處理日志的的邏輯。
這里有幾點注意的：
如果你擁有復雜的產(chǎn)品線，那么日志格式會是一個很痛苦的事情。以為這中間Storm(或者SparkStreaming)的處理環(huán)節(jié)你需要做大量的兼容適配。我個人的意見是，第一，沒有其他更好的辦理，去兼容適配吧，第二，推動大家統(tǒng)一日志格式。兩件事情一起做。我一個月做不完，那我用兩年時間行么?總有一天大家都會有統(tǒng)一的日志格式的。
如果你的研發(fā)能力有富余，或者有大數(shù)據(jù)團隊支撐，那么可以將進入到SparkStreaming中的數(shù)據(jù)存儲起來，然后通過SparkSQL等做即席查詢。這樣，有的時候原先沒有考慮的指標，你可以直接基于日志做多維度分析。分析完了，你覺得好了，需要固化下來，那再去更新你的SparkStreaming程序。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
關鍵詞標簽： 用大數(shù)據(jù)思維做運維監(jiān)控是怎樣一種體驗?,大數(shù)據(jù) 運維監(jiān)控,ERP,ERP系統(tǒng),ERP軟件,ERP系統(tǒng)軟件,ERP管理系統(tǒng),ERP管理軟件,進銷存軟件,財務軟件,倉庫管理軟件,生產(chǎn)管理軟件,企業(yè)管理軟件,免費ERP,免費ERP軟件,免費ERP系統(tǒng),ERP軟件免費下載,ERP系統(tǒng)免費下載,免費ERP軟件下載,免費進銷存軟件,免費進銷存,免費財務軟件,免費倉庫管理軟件,免費下載,
您的位置：
在線客服