近年來APM行業被愈來愈多的企業所關注，尤爲是在2014年底，NewRelic的成功上市，更加激發了人們對這個行業前景的無限遐想。那麼究竟什麼是APM?APM的目的是什麼?要求咱們作什麼?有很多企業對APM的理解實際上是有誤差的，本文將向您闡述一個真正完整的APM概念。html
APM 是Application Performance Managment的縮寫，字面意思很容易理解，「應用性能管理」。它是由Gartner概括抽象出的一個管理模型。注意，這個管理模型的由來，是通過大量調研與分析後的概括與抽象，這些切實需求由來已久，IT從業者們對它的理解與實踐也幾乎是從IT誕生至今就已開始，這並非一次發明。web
從上圖中能夠清楚看到APM模型中一共分了五個層次，下面就這五個層次逐一說明。算法
1. End User Experience編程
What：終端用戶體驗。APM首先關注的是終端用戶對應用性能的真實體驗。瀏覽器
Why：不是監測點的，也不是骨幹網核心機房的，而是真實用戶的切實體驗到的性能。可能一個電影播放服務的性能優化作得很棒，可是用戶打開瀏覽器或打開APP，發現點播某個電影時卻慢得離譜，問題會出在哪裏呢?用戶不清楚點擊播放按鈕以後，發生的一切事情，用戶只是感知到了慢、不能播放、往復播放等等不少很差的體驗，用戶反饋了問題或投訴了，產品和研發不能準確重現，問題來了。性能優化
也許用戶瀏覽器太過陳舊，也許是某個JS腳本的兼容性問題，也許用戶本地網絡丟包嚴重、首字節響應時間很長，也許是服務器集羣網絡不穩定、某組機器脫離了均衡池…… 太多也許了。而這些猜想是，最很差把控的，就是用戶客戶端環境，Server端比如自家的菜地，菜好菜賴老是清楚的，可再好的菜賣到飯館，廚子怎麼樣菜農怎麼知道?服務器
幫助應用管理者準確、詳盡地瞭解真實的用戶體驗是什麼樣子，這是APM首先要解決的問題。微信
How：對於Web應用來講，在用戶請求到的每個頁面下面追加一段js腳本，用js收集併發回數據，是最廣泛的作法;對於移動App來講，在APP發佈前build進SDK，經過系統與語言Hook來收集數據，也是很直截了當的。至於這兩者具體的作法，容後文再細聊，此篇不贅。下列簡單截取了幾張圖片，來源透視寶。網絡
2. Runtime Application Architecture架構
What：應用架構映射。
Why: 曾經與多名CTO深刻探討過這個問題(其中不乏已經上市的企業)：大家有完整的應用架構圖嗎?獲得的回答很多是閃爍其詞的，有的CTO很直接地搖搖頭。更有甚者是這麼回答的，公司應用系統年代久遠，就算目前全部的架構師專職繪圖，也很難在短期內完成所有的應用架構圖。
大多數企業的應用架構，是黑盒或灰盒，這就是現狀。
假如應用架構圖是完整的，那麼還有一個需求即：針對於某次故障請求的真實請求鏈路拓撲。是的，負載均衡一共分發了N臺機器做爲集羣，但承接某次具體請求的是集羣中的某些機器，那麼，是哪些機器?它們當時的性能是什麼樣子?請求順序是怎樣的?
How: 雲智慧透視寶實現了應用的完整架構：
與單次請求的應用架構：
能夠看到，在上面的示例中，完美瞭解決了咱們在應用架構層面遇到的問題。
具體作法，咱們將在後續文章中單獨介紹，其中包含了web容器插件、編程語言Hook插件等技術細節。
3. Business Transactions
What：應用事務分析
Why：固然這裏說的事務不是DB事務。這裏指應用與用戶交互的操做事務。舉個例子：用戶登陸網站後，使用搜索功能搜索了耳機，從耳機列表中，選擇了本身喜歡的耳機，打開查看詳情，款式音效價格看來都不錯，放入購物車，而後打開購物車進行購買，完成支付。
整個例子中，咱們所說的事務能夠抽象爲：
登陸 -> 搜索 -> 挑選 -> 購買 -> 支付
因此，單純的記錄登陸成功率、購買成功率的意義不會至於大到分析整個應用的健壯穩定程度，準確地分析出總體事務的相互影響象限，纔會。
How：熟悉GA的朋友都知道，GA花費了大量的力量以實現上述咱們所描述的應用事務。但令開發者痛苦的是，必需要在代碼中「埋點」，即在代碼中的關鍵位置寫入一行代碼，以實如今關鍵位置的追蹤，而業務總不是一成不變的，因而隨着業務發展，「埋點」這個事情使得應用總在不停地修改、發佈、修改、發佈。
其實，用戶在客戶端(瀏覽器、APP)所進行的全部操做，很明顯，是有序的。要完成應用事務的記錄，要完成的需求其實只是兩個唯一性：
一、肯定上下文的事務操做，是同一個用戶;
二、肯定全部事務操做的每個步驟，是唯一一個動做。
因而咱們即可對某一個應用取得的數據分析出如下應用事務，而整個過程當中，用戶不須要修改任何一行代碼(無須埋點)。具體的實現細節，後續會專門出文介紹。
4. Deep Dive Component Monitoring
What：深度應用診斷
Why：關鍵詞是「深度」。好比某在線商城，接到了上海用戶的反饋，登陸慢，不響應。這其中可能出現問題的環節太多了：CDN可能有問題、Web Server或DB Server負載可能太高、業務代碼中可能有bug、中間件可能不響應、甚至任何一個環節的物理磁盤或物理網卡可能出現了故障，等等。想要準確地找到問題所在，即便不經一番寒徹骨，八成也要先打個冷戰。
How：這裏有幾個難點是：
一、在不修改用戶代碼的前提下，取得代碼運行時性能數據;
二、終端用戶數據、運行時性能數據、物理指標數據、服務運行指標數據，有效關聯;
三、有太多需關注的點，怎樣方便快捷地部署採集端;
四、不影響或不多影響原應用性能。
以上也正是APM提出的需求。
一鍵式的、無干預的安裝部署與更新升級，以替代繁瑣的部署與升級;採用各個語言的底層Hook來針對性地編寫語言Agent插件，以此實現不修改用戶代碼而取得運行時性能數據;經過主機、應用、服務、請求的唯一標識，來進行有效的數據關聯;經過特有的數據採樣算法來達到2%如下的性能影響;一體化的數據模型，以替代密集的數據孤島。這段特徵，描述的是雲智慧透視寶的Smart Agent。(一樣，實現細節請待後文。)
5. Analytics / Reporting
What：分析與報告
Why：簡單地講，APM對數據有兩點要求：
一、數據處理要及時，必要時候要作到實時的處理，問題可能隨時都會發生;
二、數據的分析報告要精確，大量的數據自己是無價值的，按照業務模型進行精確分析、預測纔有其價值體現。
How：APM數據是自然的大數據，符合4V特徵。所以難點幾乎與大數據處理的難點相重合：
一、數據模型語言要統一
二、數據存儲與查詢
三、大量複雜數據的關係建模
能夠看到，雲智慧透視寶架構中Pipe Cluster的設計是對流數據的處理的核心部分，分佈式、集羣部署的Pipe Worker可實現實時的消息消費，同時基於此架構的Data Platform與Alter Engine可實時對任意維度的數據進行分析與預警。目前數據採集量720億條/天天，共存儲200,000億條數據。(後續將對此架構進行專文介紹。)
下圖是對比了國內外APM行業的各廠商對以上APM模型中五個層次的認識與支持程度：
歡迎關注微信公衆號：shoshana