為了加深EGO會員之間的相互了解，同時也為大家提供更多線上相互學習交流的機會，EGO正式啟動會員群線上分享活動。本文是根據陳靖華分享主題“APM的價值”的內容整理而成。
第二期分享嘉賓：陳靖華，EGO會員、聽雲CTO、北京基調網絡股份有限公司聯合創始人之一。
今天我們來聊聊APM技術，首先APM是應用性能監控（Application Performance Monitoring）或應用性能管理（Application Performance Management）的縮寫。所謂應用性能管理，就是指使用特定的工具和過程對軟件應用的性能和可用性進行監控和管理，致力於發現、診斷並定位復雜應用的性能瓶頸和故障，以保證應用達到預期的服務水平和用戶體驗。
APM的歷史
應用性能的監控和管理作為一個運維的監控和管理手段實際上已經存在了很長的時間，但是APM被作為一個細分領域的IT解決方案行業被單獨提出來還是在近幾年的事情，大概在2010年左右吧。
這個從Google趨勢上可以很明顯看出來。而著名的IT研究和分析公司Gartner也是在2012年開始每年發布APM行業的魔力象限報告的。
APM從其發展階段上可以分為兩個階段，第一代的APM（我們稱作APM 1.0）是在上世紀末期由Wily, Quest Software, Mercury等公司提供的一系列系統和應用的性能采集工具，可以用來監控和分析當時典型的三層架構的應用的性能，APM 1.0相對比較笨重，基本以本地軟件加硬件的形式來提供，需要用戶投入大量的精力和成本來進行實施和維護。
第二代APM，也就是所謂的APM 2.0大概就是在2010年左右興起的，這一代的APM產品面向的是大量采用分布式SOA架構、消息總線和彈性虛擬化、雲計算框架的應用，因此APM 2.0引入了應用拓撲邏輯的自動發現來更好地監測分布式的應用。
同時為了適應敏捷開發和持續交付帶來的應用代碼的頻繁更改，APM 2.0引入了自動插樁技術來實現監控代碼的部署，用戶不需要修改任何代碼或者僅需要修改極少的代碼即可快速靈活地部署APM探針實現監控，極大地節省了部署和維護APM的成本。
相比APM 1.0另外一個比較重大的變化就是APM 2.0中終端用戶的用戶體驗成為了關鍵的監測項目，這是由於在互聯網和移動互聯網的應用交付場景下，越來越多的業務表現都依賴於應用本身的服務質量和最終的用戶體驗。
APM服務的SaaS化也是APM 2.0的一個重大變化，原有的APM 1.0產品基本上都是私有化部署的本地軟件形式提供的，APM 2.0的服務SaaS化讓用戶可以以更便利、更低成本的方式來快速部署和使用以前價格高昂，部署和維護困難的APM產品。
APM的作用
APM能幫我們做什么，或者說在我們已有的運維監控體系中，APM能帶來哪些不同的價值呢？我們可以從Gartner APM魔力象限里對APM服務5個維度的定義來看看APM到底能做什么，這5個維度的定義從2012年到現在基本上沒有太大的改變。
第一個維度最終用戶體驗監測（EUEM）
這要求從端到端（客戶端到服務器端）來采集最終用戶訪問應用時的性能體驗，包括端到端的網絡延時，應用響應時間，響應的成功率和質量等等。最終用戶的體驗監測除了從真實用戶的訪問（RUM，Real User Monitoring）來進行之外，還可以通過主動式的模擬最終用戶監測（Synthetic Monitoring）來進行應用可用性的評估。
最終用戶體驗監測始終是APM最重要的維度沒有之一，這也是APM與傳統運維監控的最主要差別。
傳統運維監控一般都是自下而上的監控，關注點在系統和服務層面，通過對基礎架構、系統、服務、應用的監控來保證服務的高可用和應用的體驗效果。而APM是自上而下的監控，關注點在最終用戶的體驗層面，通過對用戶體驗、網絡、應用以及服務的監控來保證應用的高可用和體驗效果。
舉個例子
從傳統運維的后端監控上除了流量和訪問量的異常之外，往往很難感知到某些區域或者某個運營商的最終用戶已經訪問不了我們的網站和應用了，即使從流量異常感知到了用戶訪問量的減少也很難定位問題。而從APM的EUEM上，我們可以非常及時准確地發現並定位最終用戶無法訪問的原因。由於EUEM，我們經常比我們的IDC服務商和雲服務商更早發現他們的各種網絡故障，往往我們給他們打電話、發消息投訴的時候他們自己還完全一無所知。
第二個維度應用拓撲邏輯發現和可視化
它指的是能自動識別應用在執行的過程中涉及的軟硬件架構和組件，並且可以描繪出應用交付鏈中相互通訊的各種組件的訪問路徑，也就是我們通常說的調用鏈。
這一個維度也是非常重要的，通過該維度的實現，我們可以將應用的調用鏈通過拓撲圖，調用圖等圖表可視化，直觀地展示應用的拓撲邏輯。這個維度最直觀的的一個實現就是提供全鏈路的應用拓撲圖。
第三個維度用戶定義的事務剖析
它要求從用戶請求的角度來對事務中的用戶定義的事件進行追蹤。這個字面上可能不太好理解，實際上這個意思是可以根據要求對特定的用戶訪問特定的事務請求進行完整的追蹤，包括在整個請求過程中涉及到的第二個維度要求中發現的服務和組件。例如當發現性能問題的時候，可以跟蹤一個特定（用戶名，手機號，用戶ID等等）的用戶在使用App訪問購物流程中的的每一個步驟的訪問情況，采集每一個請求中的最詳細的代碼和服務、組件訪問性能和異常數據。
第四個維度應用組件深度鑽取
這要求對第二個維度里發現的服務和組件的資源消耗和事件提供足夠細粒度的監控。例如對應用訪問的數據庫服務，MQ服務等提供深度的監控，當發現有數據庫服務查詢性能問題的時候，可以提供包括完整的SQL語句，執行計划，數據庫狀態等在內的詳細監控數據。
第五個維度IT運營分析（ITOA）
它其實就是運維數據分析，要求使用以下技術的組合來進行運維數據分析：復雜事件處理，統計模式發現與識別，非結構化數據索引、查詢和推斷，拓撲邏輯分析，多維數據庫檢索和分析。這里的數據分析技術都是為了對APM采集到的大量的各維度性能數據進行實時的運算和處理，從而對應用的運維和優化起到輔助決策和驅動。例如通過實時的智能基線和異常監測來驅動警報系統。
從實際的應用場景上，APM可以在以下方面為我們提供幫助：
-
最終用戶體驗評估和優化，提升用戶體驗，提高應用DAU和留存
-
鏈路監控，線路優化
-
機房選型，第三方服務（CDN、雲服務、推送等）選型
-
競品性能對標
-
劫持分析和優化
-
實時告警和通知
-
業務流程代碼級的監控和優化
-
業務壓測和性能剖析
-
快速發現和定位性能問題，減少業務故障恢復時間
實際案例分析
分享幾個我們處理過的案例：
案 例 1
大概一年前我們有個客戶通過最終用戶的監測發現上海聯通大概有30%的手機用戶無法訪問他們的App，但是從他們自己的后端運維監控系統上完全看不出來這樣的區域故障，甚至憤怒的用戶跑到他們上海的辦公室鬧事了都還不知道怎么回事。
最初我們通過真實用戶的監控（RUM）數據發現無法訪問的錯誤大部分都是“無法建連：連接被重置”的錯誤，然后通過主動式的對比監測發現同樣的上海聯通3G手機，訪問其他域名沒有任何問題，而一旦訪問這個客戶的域名就出現上面說的那個錯誤，非常像是對特定域名的劫持。但是和運營商溝通之后他們否認有劫持。
然后我們又對比了主動測試里可以正常訪問和無法訪問該域名的探測點的數據，結果發現使用聯通預付費電話卡的訪問是正常的，而使用后付費電話卡的無法訪問。很明顯這與費用的結算有關系，於是又與運營商溝通，最終確認是客戶公司與聯通在做活動，對使用該客戶App的用戶進行免流量的活動，但是由於聯通內部工單下錯，一個需要后做的步驟給提前做了，最終導致所有后付費的用戶無法使用。定位了問題之后，運營商那邊很快就把問題解決了。
定位和解決客戶端的問題，特別是運營商和網絡方面的問題通常是比較費時費力的，有了最終用戶的體驗數據之后往往可以快速幫助我們縮小問題的范圍，實現更快地定位。而對應服務端的應用來說，問題的解決相對比較可控，而我們需要的就是快速發現和定位代碼和服務上的性能問題，以便更快地解決，減少故障恢復時間和對業務的影響。
案 例 2
大概也是去年3月份中旬的時候，一個電商客戶做他們一款新產品的上線和微信促銷活動。
活動當晚8點多的時候，當流量上來以后，整個系統完全都不能用了，App和微信平台上的訪問幾十秒都打不開。整個項目組的人都忙作一團希望盡快定位問題，但是由於系統的架構復雜，調用的組件多，並且在之前開發的時候沒有輸出足夠詳細的日志，導致問題定位非常困難。
最后他們的技術老大臨時決定要裝上APM探針試試，9點鍾開始找了幾個應用實例部署了應用探針，跑了十幾分鍾數據后就基本上定位了問題：
一個是應用代碼的問題導致Redis緩存層失效，所有的訪問都基本直接訪問數據庫，導致數據壓力瞬間變大，數據庫的單次連接時間飆升到了15秒多；另外一個是調用他們公司另外一個系統的接口問題，當時的接口調用也到了每次請求7，8秒的耗時。
定位問題后，很快找研發修改代碼，大概在10點的時候把問題解決掉，系統的響應趨於平穩。整個過程，從安裝探針到定位問題大概用了十多分鍾，到最終把問題解決掉一共不到一個小時的時間。
現在很多電商客戶在上新的產品或各種x18,雙xx活動前都會使用APM工具進行壓測和性能分析，提早發現可能存在的性能問題。活動的時候也會實時關注各應用的性能數據，來進行及時的應用擴展和故障恢復。
上面列舉了一些APM的典型應用場景，來幫我們理解APM可以幫助我們干什么，總結下來就是：APM可以幫助我們從最終用戶角度和業務角度了解我們的應用的性能和業務表現，為優化用戶體驗和提升業務表現提供依據和驅動力。