如何從0開始 搭建應用監控架構？

隨著業務系統的不斷迭代建設，基于現有的日志監控系統或報警平臺，是否能夠精準的定位問題根源及自動化實時捕捉微小的異常或錯誤在系統運行的過程中會有什么樣的影響？面向業務提供全棧性能監控和分析的訴求凸顯越來越重要，本文將結合應用監控架構設計的最佳實踐原則（《架構即未來》第三十一章節“應用監控”），結合實際的監控架構設計的思路，引申出應用性能監控建設架構并結合實際案例加以介紹。

“系統事故對企業的損失不言而喻，與其投入重點精力做時候的補救，倒不如提前在之前做好架構設計和業務應用監控。” ——摘自《架構即未來》之應用架構核心思想

監控架構的核心思想

當企業處在快速成長的時期，業務系統也在不斷的迭代更新中，如若無法快速識別系統可擴展的瓶頸，必將遭受長期的系統服務中斷的痛苦，因為任何微小的異常隱患或程序報錯的發生，輕則影響用戶體驗，造成用戶埋怨不斷，重則可能會引發系統的故障，如業務系統宕機這般災難性的故障。

在參與過往的業務系統應急處理過程中，經事后RCA（Root Cause Analyze ）的源頭分析發現均有共同點，就是引發錯誤的根源被隱藏極深，在事故處理過程中很難短時間內發現源頭的端倪，即便通過了嚴格的業務變更評審及DBA細致的SQL走查，終究會有一些“漏網之魚”，而這些問題通常在標準的業務覆蓋回歸測試中很難被發現，也只有在生產運行后的一段時間，被某種“神奇的力量”觸發。要想做到事前預防或在最佳時期處理清楚問題隱患，確保業務大規模上量后能夠穩健的運行，則需要思考的問題是 “基于現有的日志監控系統或報警平臺，是否能夠精準的定位問題根源及自動化實時捕捉微小的異常或錯誤在系統運行的過程中會有什么樣的影響？”  

如果想要能精準定位并具備相應的能力來捕獲這些“漏網之魚”，便離不開應用監控架構的思路來指導。因為要完成這件事情，有過行業經驗的朋友或專家會告訴你，這不僅僅需要有大量的信息來搜集和檢索，如統一的大數據日志監控系統（ELK），還得要有非常得力的應用性能管理（Application Performance Management）工具如云智慧透視寶進行7*24小時實時的監測分析，一旦出現問題可以做到秒級甚至毫秒級別的快速捕捉問題，通過配套的自動檢查分析機制，來篩選并驗證一些細小的錯誤，在通過共性部分來反查應用代碼，刨根問底，發現存在的隱患是不是引發災難源頭。比如發生了故障，首先會考慮的是“出問題了嗎？”之后就是“出什么問題了？”然后就是“問題出在哪里？”最后便是“是什么問題？”隨著問題的遞進和深入，所需要回答和準備的數據也越來越多，這也是數據規模與問題針對性之間的重要聯系（見下圖），作為架構設計者和事故處理負責人必然會問到的這四個核心問題。 圖一：數據規模與問題針對性之間的關系，摘自 “《架構即未來》第三十一章 應用監控架構P31.3”

應用監控架構的核心思想就是幫助運維改變這樣的窘迫局面：“每次發生系統級別故障，花費很長的時間去定位引發故障的根源如變更的步驟遺落、代碼編寫不規范、業務SQL的超出標準等，這些根源所引發的問題都不一樣，都需要經過各式各樣的應急去處理，直到事后的問題整改，完成故障的閉環。看似標準符合邏輯，但這樣周而復始下去，往輕的一方面解讀是在業務上所反饋出來表象便是讓商戶或用戶不斷的試錯，正常的業務交易中斷，逐漸地喪失了對產品的信心；往重的方面去分析，業務系統的故障，會增加企業的運營成本，甚至影響核心的技術團隊實力”我們不妨換個思路來，首先解決“問題發生之前有盡早發現故障前兆的報錯或者異常信息？”，因此，引申出了我們在進行業務應用監控架構設計的核心思想，這也是為客戶提供更好的服務水平承諾（SLA：Service Level Agreement）的標準化結構設計重點。為提升用戶體驗，系統的平均響應時間（ART：Average Response Time）和有效成功率（EST：Effective Success Rate）這兩大指標也是面向應用監控可量化衡量的參考依據。

監控系統的設計指導與框架模型

監控設計指導

為了能夠清楚意識到 任何微小的延遲都可能預示著明天的局部停機或者系統癱瘓， 遵循通用監控系統設計的指導思想，需要進行對業務系統的劃分：

1） 面向IaaS平臺：包括但不限于硬件底層、操作系統主機、數據庫、網絡等；

2） 面向PaaS平臺：如SOA公共框架（SOA框架、Dubbo服務等）、公共組件（緩存Redis組件、消息隊列RabbitMQ組件等），公共服務子系統或公共服務平臺等；

3） 面向SAAS服務：如提供業務服務的HTTP、API、SDK、APP、SOCKET等；

遵循分層的設計原則，企業級監控系統的采集周期（頻次）必須能夠細化到秒級甚至毫秒級別，監控數據必須完整覆蓋天、周、月、年的單位，歷史監控數據必須完整存儲超過3年以上的時間，這也是對重要監控系統最基本的需求。其中，所設計的監控系統要面向的目標對象(Goal Object)必須能夠準確反映出可用性狀況、性能瓶頸指標、對外提供服務的SLA指標（ART&EST）等，如果是面向應用型監控系統，不僅僅能夠完整的顯示出應用中間件或容器的JVM等各類指標，包括但不限于GRP:GlobalRequestProcessor，BusyThread，JCA:JavaConnectionAvailable，MaxReuqestTime，AverageResponeTime等），而且可以捕捉到WebServer在運行過程中，應用系統中各方法類的性能開銷狀態，出現故障如果可以進行做追述和定位的時候，還能細化到開銷方法的全棧追蹤到每個數值，那這樣的業務應用監控架構的設計就非常的完整，即通常我們所描述的監控系統的顆粒細度以及能夠對重要的系統、業務、安全等指標進入預測分析。

 圖二：通用監控系統設計指導思想

企業監控框架

對于企業內部趨向于成熟的監控框架通常會來行業通用的結構來部署，這個結構需要將 監控、分析與控制 完成三位一體的無縫融合。本人的切身感受而言， 一個好的監控架構不僅僅能夠建設基于現狀及未來發展提供有效的監控預警支撐，而且可以通過平臺內實時或積累的系統或業務監測數據進行聯動分析，找出問題的瓶頸點或未來的增長點，提供系統成長重要的數據決策支撐。

簡單來說，監控系統框架分為如下三個部分：

統一監控

1） 基礎層面的監控：通過選取開源或主流的監控系統，完成公共設施或系統運維方面的有效監控，如OpenNMS-Cacti聚焦網絡層面； Zabbix/Hyerpic HQ聚焦IaaS公共層面；監控寶聚焦網站、API等。無論何種監控系統只是一種實現系統生命周期的有效運維工具，對工具本身的熱愛及對工具所涉及的技術選型最好的依據主要是能夠融會貫通，舉一反三。因為沒有任何一款監控工具都適用于所有公司的監控需求，基于量體裁衣以及在主流被廣泛使用的系統，同時兼顧了為日后統一監控中心的數據融合所準備的，能夠通過DevOps結合的監控系統才是最適合自己的。

2） 有效的應用性能監控：除了WebServer的各層基礎運行指標，因代碼BUG或者程序設計不當所引發的各種級別故障越來越多，對于企業來講，業務代碼的變更需經過嚴格的覆蓋測試，甚至會在對外發布后進行全回歸覆蓋測試及在必要的時候進行性能壓力測試，但漏網之魚依然存在，而且企業通常很難做到7*24小時的實時業務性能檢測分析，特別是在多業務復用的情況下，具體引發的問題根源無法在短時間內被快速定位和追蹤到，這也是過往業務監控的一個短板，如何準確定位到業務代碼級別的故障和異常，捕捉的信息能夠直接為開發工程師提供第一手的信息反饋，確保業務高峰來臨前能夠被準確的發現修復， 我將在下文通過透視寶的實踐操作來加深這方面的介紹。

3） 統一的業務日志平臺：ELK（Elastic+Logfluent+Kibana）已然成為行業的標桿或首選，盡管市面上有很多主流的商業化產品，但對本人而言，更加青睞自身DevOps研發建設出一套大數據如日志監控系統，因為這也是作為一家互聯網科技公司的技術標配，這樣不僅能夠個性化定制和配置，還能無縫對接集團或公司業務的特殊監控訴求。

4） 開放的API監控：能夠完成如業務API的有效性監控，做到接口數據相關的故障分析，實現對系統的彈性預測、耗損/過期分析、顆粒細度的定位位。

圖三：企業級監控系統框架參考

APM應用性能監控系統介紹

“工欲善其事必先利其器”，做到代碼級別的監控故障分析，提供7*24小時不間斷的業務檢測，就離不開專業有力的應用性能監控工具或平臺，精準的應用性能監控分析也是業務上線后穩定健壯運行的重要保障。

應用監控

應用監控很重要，它能幫助我們回答“是什么”的問題。通常情況下，要確定“是什么問題？”我們需要特別編寫一些監控代碼或者需要有能夠監控代碼的工具，如果想要把它做好，我們可能需要把代碼集成在產品或業務系統里。盡管有一些代理會告訴我們到底問題是什么，比如由于一個或多個磁盤損壞而導致的I/O子系統緩慢，但很少有現成的代理可以幫助我們準確地診斷出應用的哪一部分出現了問題；又比如一個在成熟運行的業務所依賴的子系統，經過近期的幾次業務代碼變更后，如公共子系統的Redis的效率變得越來越差，所有依賴這些公共子系統都會連帶收到系統卡頓或者響應超時的報錯。雖然那些完全自我愈合應用有點像白日夢，從開發時間的角度看，也不太經濟劃算，但是 應用可以對最常見類型的故障進行自我診斷的理念，是一個令人欽佩而且可實現的愿望。

以Java應用系統為例，JVM自身提供了相應的性能監控手段和工具，但這些分析工具主要是 側重Java單方面的性能分析 ，需要通過我們的監控架構設計思路和框架，重新設計一套符合企業業務需求的應用性能監控系統，加入能夠精準做到定位出代碼級別的監控又或者實時抓取出異常的業務SQL及事務，配合可視化分析和預警，應用性能監控系統就可以直接、快速、有效的找到癥結所在，并直觀的把關鍵信息反饋給相關開發、運維人員。

比如現在有一套業務涵蓋A,B,C之間的子系統（Subsystem）之間的調用關系，可能是Dubbo服務調用的、或是HTTP、Hessian、API等接口、又或是Rabbit MQ消息隊列、異步線程調取等方式。總之，業務系統中的各子系統之間關系均采用到的主流技術來實現構建，那么如何完成發現A子系統的應用代碼問題是通過B并對C造成問題的根源呢？

APM（Application Performance Management）的性能監測分析可以做到這一點，以云智慧透視寶為例，APM不僅能夠在復雜系統中追蹤服務及代碼層級性能瓶頸，還能自動發現全局應用拓撲，做到端對端的應用分析概覽，失誤監控與分析，SQL腳本性能分析、代碼堆棧抓取以及事務深度追蹤等，幫助開發等部門提升工作效率。

透視寶APM監控架構思路

APM數據采集架構設計

應用監控結構思路

透視寶的數據采集使用Sendproxy為SmartAgent的調度器，所有SmartAgent的數據都經過Sendproxy進行統一調度發送，推送到統一的大數據日志分析平臺。

其主要優勢在于

1） 發送隊列保證各插件數據發送的穩定性；

2） 可以作為代理，部署在可聯外網的主機中，保證局域網非聯網環境的數據發送；

APM部署調試

1、 客戶端簡易安裝

登錄透視寶網站后臺控制面板，在配置頁面下載對應操作系統的Smart Agent，進行Smart Agent的安裝和啟動。

[root@sjm6-3G-qatest01-30 smart_agent]# ./SmartAgent.sh start

Starting SmartAgent daemon: SmartAgent

Restarting SmartAgent SendProxy daemon: bin/SendProxy

No Server (/apps/smart_agent/plugins/SendProxy/bin/SendProxy) running

Starting SmartAgent SendProxy daemon: bin/SendProxy

OK

OK

備注：

1、SendProxy: 通過SendProxy發送的數據。

2、 注冊JavaAagent的應用監控服務

要監控Java應用，您需要在“插件管理”頁面中安裝并開啟Java插件。

3、提供JavaAagent的部署

點擊“安裝”按鈕安裝JavaAgent 插件，安裝時自動將JavaAgent下載到SmartAgent安裝目錄的smart_agent/plugins下，下載完成后開啟插件。安裝Java插件后，您還可以在Java插件conf目錄中的app.conf文件中配置與數據采集相關的參數。

#/apps/smart_agent/plugins/Java_1459929876X1002x0 

if [ "$1" = "start" -o "$1" = "run" ]; then 

export JAVA_OPTS="$JAVA_OPTS  

-Xbootclasspath/p:/apps/smart_agent/plugins/Java_1459929876X1002x0/conf  

-javaagent:/apps/smart_agent/plugins/Java_1459929876X1002x0/lib/CAgent-1.0.0.

jar=/apps/smart_agent/plugins/Java_1459929876X1002x0"

fi 

添加到TOMCAT的Catalina.sh的啟動文件，見下圖：

4、透視寶APM監控分析后臺管理效果

配置需要大致兩分鐘，之后就可以在“應用”模塊中查看數據，下面就是內網測試機部署的環境效果分析：

5、APM監控實時發現異常堆棧事務

通過透視寶，可以實時定位到異常堆棧事務的最緩慢元素，幫助開發人員快速解決代碼問題，確保業務的正常運行。

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzAwNzA0NTMzMQ==&mid=2653202747&idx=1&sn=1f7b7425416a83c83accde49faad88bf&chksm=80d42087b7a3a9915e92be57daeb7ddfc1f3942908e772c01f00e33b9da3b3f601cf089e691c