[APM] 解讀APM技術分類和實現方式

在講了APM的歷史、做用和實際案例以後，下面咱們來了解一下APM技術分類和實現方式以及它將來的發展趨勢。在這以前，咱們首先須要瞭解一下典型的互聯網或移動互聯網應用的整個應用交付鏈。

圖1

上面這張示意圖給出的就是一種典型的互聯網應用的應用交付鏈，在這個應用交付鏈最左端是部署在機房或雲服務商上的相對可控的區域，例如負載均衡、Web服務、應用服務器、數據庫、消息總線、存儲、等等。越往右就是離應用的最終用戶越近的部分，會涉及到機房或雲服務的鏈路，第三方的服務（例如雲服務、CDN、推送、地圖等等），用戶設備接入的本地運營商、移動運營商、用戶訪問應用使用的不一樣終端設備，瀏覽器等等。

全部圖上標註了炸彈的位置，都是整個應用交付鏈裏容易出現性能問題和下降用戶體驗的問題點，例如瀏覽器或設備的不兼容、2G/3G/4G網絡基站的擁塞、各地無良運營商的劫持、CDN節點的故障、第三方API接口的限流策略、骨幹網運營商的線路維護、以及服務端的代碼、服務、資源等問題。全部這些問題都是APM須要關注的問題，理論上，從左到右，對運維和研發人員來講，整體的可控度是遞減的，而APM的引入就是但願能提升運維和研發人員對這些問題的可控度、下降TTR。

所以APM須要關注或者說須要採集數據的位置也就是圖上的這些炸彈的位置，而不一樣位置的數據採集就帶來了APM技術的不一樣分類。

APM技術分類和實現

從APM監測部署的位置（或者叫作數據採集位置）來分，基本上能夠分紅客戶端和服務端兩大類技術。分別針對最終用戶側和應用服務側的APM技術。咱們一般說的端到端的應用性能管理，指的就是從這兩端來實現的APM技術組合。

圖2

從客戶端角度的APM技術分類上來看，又能夠分爲主動式的APM客戶端監測技術和被動式的監測技術兩大類：

主動式的客戶端監測技術稱爲SyntheticMonitoring：Synthetic，從字面的意思翻譯是人工合成的，也就是說這種監測技術的數據採集不是真實用戶產生而是人工模擬出來的，經過探針模擬真實用戶的訪問行爲來對應用進行主動式的訪問來採集數據，也就是一般說的撥測。這種監測方式須要部署必定數量的監測節點，經過定時調度的計劃來主動訪問應用來採集數據。

主動式監測因爲監測節點可控度很是高，理論上你能夠利用這些監測點作任何的數據採集，所以此類技術的適用場景包括作應用性能特別是可用性的監測，作對比測試（例如IDC/CDN/雲服務商的對比和選型），競品對標，壓力測試等。

因爲主動式監測使用的是模擬的樣本數據，須要有足夠多的樣本才能模擬出真實用戶的性能體驗，不然會存在較大的樣本誤差，致使錯誤的結論。因此，若是要部署大量的監測節點的話，成本仍是比較高的，所以目前此類監測不多有本身部署的，大部分使用的都是一些廠商提供的第三方監測服務。

被動式客戶端APM監測技術稱爲RUM：即真實用戶的監測，利用的是真實的用戶對應用的訪問來採集性能數據。RUM有一個自然的優點就是基本上沒有樣本誤差，當全流量採集數據的時候，採集到的數據就是你的用戶的真實體驗數據。目前客戶端的RUM技術會覆蓋兩部分的典型應用：WebApp和NativeApp，這裏面固然也包括如今比較流行的HybridApp。

從客戶端採集真實用戶的性能數據基本上用的就是埋碼這一條途徑了，對於WebApp，經過頁面上插入JS，利用現代瀏覽器提供的NavigationTiming（https://www.w3.org/TR/navigation-timing/）和ResourceTiming（https://www.w3.org/TR/resource-timing/）接口來採集性能數據。

圖3

圖4

雅虎的Boomerang就是基於Web頁面埋碼的性能數據採集框架。

固然並非全部瀏覽器都能很好地支持這些標準接口的，例如iOS8.0.1之後的全部iOS8版本就是由於性能的問題去掉了NavigationTiming接口，不過好消息是在iOS9以後這個接口終於又回來了。

下面這兩個圖列出的目前各類瀏覽器版本對這兩個API接口的支持程度。

圖5

圖6

而對NativeApp的RUM監控就沒有什麼標準的接口能夠用了，若是想本身作的話通常依賴於研發人員手工埋碼，或者在開發App的時候使用一套統一的框架來進行埋碼和採集。

目前APM行業裏一般的作法是提供一套能夠自動埋碼和採集數據的SDK來自動完成監控代碼的注入工做。經過這種方式能夠作到開發人員只須要修改少許代碼甚至一行代碼都無需修改就能夠集成RUM的數據採集功能到App中。這裏使用到的自動代碼注入技術與服務端監控的代碼注入機制相似。

圖7

如圖，經過在須要監控的方法（例如：須要監控HTTP訪問請求的性能，須要監控的方法就是HttpURLConnection,AndroidHttpClient等類下的方法）外面包上一層監控代碼來採集方法的執行時間，異常等信息。

在Android上實際上還能夠有多種代碼的注入方式：

圖8

在編譯打包過程注入，經過-javaagent加載探針的方式在dex轉碼階段直接對字節碼進行修改來加入監控代碼。

在C代碼層面進行注入，對一些底層和native方法（例如DNS解析部分的性能採集）的監控，一般使用C對應用進行代碼注入和掛鉤子。

直接修改APK包中的字節碼，一般的步驟是APK解包，反編譯成smali，修改smali代碼再從新編譯打包回去。這種方式不須要用戶提供源代碼便可完成監控代碼的注入，不過對混淆過的代碼這種方式就比較困難了。

在iOS上一般也有多種技術來對代碼進行注入，例如使用swizzle的Object-Chook，消息轉發和修改符號表技術等等。

客戶端的RUM一個很是重要的技術難點就是對客戶端資源的消耗的控制。包括計算資源（CPU，內存）以及網絡資源（流量）。對計算資源的消耗最終可能影響應用自己的性能，若是控制很差會變成爲了作性能監測反而引入新的性能問題。

所以對性能數據的採集上通常會對不存在性能問題的樣本數據在客戶端上下降採樣比例或者是隻採集簡單的彙總數據，而只對超過性能閾值和異常的數據進行詳細的數據採集。一樣在客戶端進行一部分的數據彙總和合並，（例如短期內，客戶端發生同一種網絡故障是每每是重複出現的，能夠合併之後再上報），在不一樣網絡環境下使用不一樣的數據上報策略，這些均可以極大地下降對網絡流量的消耗。

再來看看服務端的APM技術。目前比較經常使用的服務端APM技術大概能夠分爲如下四種：

無探針技術：無需安裝探針，經過系統或服務自身提供的狀態接口來進行組件的性能和狀態的監控，例如經過SNMP等協議實現的監控，這種監測技術你們應該比較熟悉了，例如常見的Cacti,Zabbix等工具都屬於這一類型的監控技術。無探針技術目前是做爲APM中的輔助技術來提供第四個維度的應用組件性能和狀態數據的。

日誌分析技術：日誌分析能作的事情很是多，其中一部分就是APM，實際上日誌分析是APM中很是重要的一種補充。經過採集系統、組件和應用的日誌並進行實時的分析來進行性能評估和問題的定位。目前比較熱門的ELKstack（Elasticsearch,Logstash,Kibana，參考：https://www.gitbook.com/book/chenryn/kibana-guide-cn/details）就是這方面技術的應用。

NPM技術：此類技術使用的是網絡協議包監聽和分析的技術來實現的應用性能管理，其實是屬於NPM（NetworkPerformanceManagement）領域的產品，用在APM領域的時候一般叫作aaNPM（ApplicationAwareNetworkPerformanceManagement，應用感知網絡性能管理）。NPM的廠商比較多了，也有一些開源的產品例如ntop（http://www.ntop.org/）你們有興趣能夠了解一下。aaNPM能夠採集足夠詳細的應用網絡性能方面的數據，可是沒法提供代碼級別的性能數據。

應用內探針技術：這個應該是目前APM行業裏比較流行的技術，使用的是運行在應用內部（應用服務器上）的探針，因爲探針與用戶的代碼在一塊兒運行在應用內部，所以能夠採集到很是詳細的性能指標數據和業務指標數據，包括應用的響應時間，代碼模塊的執行時間，應用調用其餘服務組件或API接口的響應時間，代碼對系統資源的消耗等。

此外，運行在應用內部的探針還能夠對代碼的調用棧和應用之間的調用鏈進行跟蹤，能夠提供很是完整的業務調用棧性能數據和追蹤數據。

相比其餘三種技術，應用內探針使用的是侵入式的探測技術，具備很是明顯的優勢就是調用棧的跟蹤和代碼的定位，可是也帶來了對應用的性能和穩定性產生影響的風險。不過目前好的探針技術基本均可以作到在極低的性能和穩定性影響風險的狀況下采集到足夠詳細的應用性能數據了。

應用內探針技術一般有兩種實現方式，一種是提供一整套的SDK框架，由開發人員按照要求在須要採集性能或業務數據的地方手工埋碼來實現應用內探針的部署。這種方式典型的表明工具就是大衆點評的開源項目CAT（https://github.com/dianping/cat）了。

第二種方式使用的是自動插樁的方式來部署探針，經過JDK1.5以上版本提供的Instrumentation的特性，利用JavaAgent在應用運行的時候進行字節碼修改的方案。該方案無需開發人員改動代碼，便可將監控代碼自動注入到須要採集性能和業務數據的位置，來實現應用內探針的部署。目前大部分的商業APM採用的都是這種方式來實現的。

目前使用這種方案的一些Java開源APM項目有：

Zorka（http://zorka.io/）

Pinpoint（https://github.com/naver/pinpoint）

SCOUTER（https://github.com/scouter-project/scouter）

列了這麼多APM的技術你們能夠看到，沒有一項技術是能夠徹底取代另一項的，不一樣的APM技術適用於不一樣的應用場景。這裏給出了一張咱們本身總結的APM技術使用場景對照表。

同時在APM的技術發展上，愈來愈複雜的應用架構和應用場景，愈來愈須要將不一樣的APM技術組合在一塊兒使用，對端到端的性能數據進行相關性分析，才能快速準確地定位性能問題點。Gartner也是在2015年第一次將APM魔力象限的名稱從ApplicationPerformanceMonitoring改爲了ApplicationPerformanceMonitoringSuites.

因爲客戶端APM和服務端APM探針部署的位置差別致使各自只能看到完整調用鏈中一部分的性能數據和現象，所以只有把兩端的數據關聯在一塊兒分析才能更精確的定位問題。一樣的在服務端的應用中，完成一個業務/事務的處理每每須要在不一樣的應用系統、組件和服務之間相互調用和傳遞數據，只有將各應用和組件之間的性能數據經過業務的調用鏈關聯起來纔有可能對性能問題進行快速有效的追蹤和定位。這就是APM分析中的跨應用分析和追蹤技術，這項技術的實現就很大程度上依賴於應用內探針技術。

經過應用內探針技術，在對應用進行自動埋碼進行性能數據採集的同時，還能夠對應用的響應信息和應用對外的服務調用請求進行適當的修改，加入用來追蹤的數據（例如在HTTP請求頭裏加入追蹤的會話ID等等），而在客戶端和其餘應用組件內部的探針就能夠對這些追蹤數據作相應的處理，而且在數據採集的時候對每一個請求作關聯了。

經過跨應用追蹤技術，在客戶端就能夠迅速瞭解一個請求慢是因爲服務端的接口響應慢仍是網絡延時高致使的，而在服務端的接口數據裏，又能夠詳細地鑽取到最終致使應用的複雜調用鏈響應慢狀況下特定的服務組件或代碼。

APM技術的發展趨勢

從2014年Gartner發佈的IT運維管理的技術HypeCycle（技術成熟度曲線）能夠了解到2014年的時候，APM技術在其中的位置處於第三階段，也就是在退燒階段。在這個階段，你們對APM技術將會有更理性的認識，而在這個階段堅持下來的廠商將會推進該技術進入爬坡期，慢慢走向成熟。預計在5-10年的時間內達到平臺期。

2015年以後，原來的「IT運維管理」的HypeCycle圖被拆成了3個圖。其中，APM技術被歸類到了「IT基礎設施可用性及性能管理」這個圖裏。從2015年的新數據中咱們能夠看出來，APM的技術發展仍是比較快的，甚至快過了NPM技術的發展，預計在將來的2-5年（2014年的時候預測是5-10年）達到成熟區（平臺期）。

1.移動APM的需求會快速增加

從整個互聯網的發展趨勢來看，愈來愈多的用戶選擇移動設備而不是桌面PC來訪問互聯網，移動應用的用戶已經超過了桌面應用的用戶數。而在移動應用的體驗上，因爲移動設備屏幕的獨佔性，用戶一般對性能和用戶體驗會有更高的要求，然而咱們卻每每在移動應用上面會碰到更多的問題和挑戰，例如在設備、運營商、地理位置、網絡接入、應用開發框架方面，都存在着比桌面應用更多的各類性能瓶頸，嚴重影響用戶的移動體驗。

更進一步的是用戶對同時在不一樣的移動設備上進行無縫切換使用的要求（例如iOS的Handoff），也對移動應用開發和性能管理提出了新的挑戰。

2.APM將融合更多新興的技術，從單純的性能監控走向真正的性能管理

經過大數據，機器學習，雲，容器等技術的融合，APM將提供更智能的性能管理，例如應用基線的智能學習和計算，無需用戶設置閾值，而且在探測到性能問題和異常的時候能夠根據用戶設定的策略自動調整系統的負載調度和資源的伸縮，而不僅是僅僅通知用戶。

3.APM將更加關注最終用戶體驗和業務

最終用戶體驗一直以來都是APM中最重要的維度（這也是爲何Gartner將其列爲5個維度中的第一個），在將來的今年內，隨着移動互聯網和IoT的快速發展，對最終用戶體驗的關注將成爲重中之重。

於此同時，業務指標也將成爲APM的另一個關注點，APM將不只僅只是關注應用的性能，而會更加關注性能對用戶體驗和業務指標的影響，將業務的表現關聯到性能指標上。例如經過APM系統將能夠實時瞭解到一個數據庫查詢的故障將直接影響到多少訂單的成交。

4.用戶期待更完整的統一IT管理平臺

幾年內，微服務，雲計算，容器技術以及多語言編程的興起，將帶來愈來愈複雜的應用，對應用須要監控和管理的點愈來愈多，咱們已經看到用戶將迫切須要一個將各種IT監控和管理技術融合在一塊兒的統一IT管理平臺。所以融合APM技術以及相關的NPM、EUEM、ITOA已經BSM技術將是將來IT管理的必然趨勢。