近年來APM行業(yè)被越來越多的企業(yè)所關(guān)注，尤其是在2014年末，NewRelic的成功上市，更加激發(fā)了人們對這個行業(yè)前景的無限遐想。那么究竟什么是APM?APM的目的是什么?要求我們做什么?有不少企業(yè)對APM的理解其實是有偏差的，本文將向您闡述一個真正完整的APM概念。

APM 是Application Performance Managment的縮寫，字面意思很容易理解，“應(yīng)用性能管理”。它是由Gartner歸納抽象出的一個管理模型。注意，這個管理模型的由來，是經(jīng)過大量調(diào)研與分析后的歸納與抽象，這些切實需求由來已久，IT從業(yè)者們對它的理解與實踐也幾乎是從IT誕生至今就已開始，這并不是一次發(fā)明。

從上圖中可以清楚看到APM模型中一共分了五個層次，下面就這五個層次逐一說明。

1. End User Experience

What：終端用戶體驗。APM首先關(guān)注的是終端用戶對應(yīng)用性能的真實體驗。

Why：不是監(jiān)測點的，也不是骨干網(wǎng)核心機房的，而是真實用戶的切實體驗到的性能?？赡芤粋€電影播放服務(wù)的性能優(yōu)化做得很棒，但是用戶打開瀏覽器或打開APP，發(fā)現(xiàn)點播某個電影時卻慢得離譜，問題會出在哪里呢?用戶不清楚點擊播放按鈕之后，發(fā)生的一切事情，用戶只是感知到了慢、不能播放、往復(fù)播放等等很多不好的體驗，用戶反饋了問題或投訴了，產(chǎn)品和研發(fā)不能準(zhǔn)確重現(xiàn)，問題來了。

也許用戶瀏覽器太過陳舊，也許是某個JS腳本的兼容性問題，也許用戶本地網(wǎng)絡(luò)丟包嚴(yán)重、首字節(jié)響應(yīng)時間很長，也許是服務(wù)器集群網(wǎng)絡(luò)不穩(wěn)定、某組機器脫離了均衡池…… 太多也許了。而這些猜測是，最不好把控的，就是用戶客戶端環(huán)境，Server端好比自家的菜地，菜好菜賴總是清楚的，可再好的菜賣到飯館，廚子怎么樣菜農(nóng)怎么知道?

幫助應(yīng)用管理者準(zhǔn)確、詳盡地了解真實的用戶體驗是什么樣子，這是APM首先要解決的問題。

How：對于Web應(yīng)用來說，在用戶請求到的每一個頁面下面追加一段js腳本，用js收集并發(fā)回數(shù)據(jù)，是最普遍的做法;對于移動App來說，在APP發(fā)布前build進SDK，通過系統(tǒng)與語言Hook來收集數(shù)據(jù)，也是很直截了當(dāng)?shù)?。至于這二者具體的做法，容后文再細(xì)聊，此篇不贅。下列簡單截取了幾張圖片，來源透視寶。

 #p#

2. Runtime Application Architecture

What：應(yīng)用架構(gòu)映射。

Why: 曾經(jīng)與多名CTO深入探討過這個問題(其中不乏已經(jīng)上市的企業(yè))：你們有完整的應(yīng)用架構(gòu)圖嗎?得到的回答不少是閃爍其詞的，有的CTO很直接地?fù)u搖頭。更有甚者是這么回答的，公司應(yīng)用系統(tǒng)年代久遠(yuǎn)，就算目前所有的架構(gòu)師專職繪圖，也很難在短時間內(nèi)完成全部的應(yīng)用架構(gòu)圖。

大多數(shù)企業(yè)的應(yīng)用架構(gòu)，是黑盒或灰盒，這就是現(xiàn)狀。

假如應(yīng)用架構(gòu)圖是完整的，那么還有一個需求即：針對于某次故障請求的真實請求鏈路拓?fù)?。是的，?fù)載均衡一共分發(fā)了N臺機器作為集群，但承接某次具體請求的是集群中的某些機器，那么，是哪些機器?它們當(dāng)時的性能是什么樣子?請求順序是怎樣的?

How: 云智慧透視寶實現(xiàn)了應(yīng)用的完整架構(gòu)：

與單次請求的應(yīng)用架構(gòu)：

可以看到，在上面的示例中，***了解決了我們在應(yīng)用架構(gòu)層面遇到的問題。

具體做法，我們將在后續(xù)文章中單獨介紹，其中包含了web容器插件、編程語言Hook插件等技術(shù)細(xì)節(jié)。#p#

3. Business Transactions

What：應(yīng)用事務(wù)分析

Why：當(dāng)然這里說的事務(wù)不是DB事務(wù)。這里指應(yīng)用與用戶交互的操作事務(wù)。舉個例子：用戶登錄網(wǎng)站后，使用搜索功能搜索了耳機，從耳機列表中，選擇了自己喜歡的耳機，打開查看詳情，款式音效價格看來都不錯，放入購物車，然后打開購物車進行購買，完成支付。

整個例子中，我們所說的事務(wù)可以抽象為：

登錄 -> 搜索 -> 挑選 -> 購買 -> 支付

所以，單純的記錄登錄成功率、購買成功率的意義不會至于大到分析整個應(yīng)用的健壯穩(wěn)定程度，準(zhǔn)確地分析出整體事務(wù)的相互影響象限，才會。

How：熟悉GA的朋友都知道，GA花費了大量的力量以實現(xiàn)上述我們所描述的應(yīng)用事務(wù)。但令開發(fā)者痛苦的是，必須要在代碼中“埋點”，即在代碼中的關(guān)鍵位置寫入一行代碼，以實現(xiàn)在關(guān)鍵位置的追蹤，而業(yè)務(wù)總不是一成不變的，于是隨著業(yè)務(wù)發(fā)展，“埋點”這個事情使得應(yīng)用總在不停地修改、發(fā)布、修改、發(fā)布。

其實，用戶在客戶端(瀏覽器、APP)所進行的所有操作，很明顯，是有序的。要完成應(yīng)用事務(wù)的記錄，要完成的需求其實只是兩個惟一性：

1、確定上下文的事務(wù)操作，是同一個用戶;

2、確定所有事務(wù)操作的每一個步驟，是惟一一個動作。

于是我們便可對某一個應(yīng)用取得的數(shù)據(jù)分析出以下應(yīng)用事務(wù)，而整個過程中，用戶不需要修改任何一行代碼(無須埋點)。具體的實現(xiàn)細(xì)節(jié)，后續(xù)會專門出文介紹。

 #p#

4. Deep Dive Component Monitoring

What：深度應(yīng)用診斷

Why：關(guān)鍵詞是“深度”。比如某在線商城，接到了上海用戶的反饋，登錄慢，不響應(yīng)。這其中可能出現(xiàn)問題的環(huán)節(jié)太多了：CDN可能有問題、Web Server或DB Server負(fù)載可能過高、業(yè)務(wù)代碼中可能有bug、中間件可能不響應(yīng)、甚至任何一個環(huán)節(jié)的物理磁盤或物理網(wǎng)卡可能出現(xiàn)了故障，等等。想要準(zhǔn)確地找到問題所在，即使不經(jīng)一番寒徹骨，八成也要先打個冷戰(zhàn)。

How：這里有幾個難點是：

1、在不修改用戶代碼的前提下，取得代碼運行時性能數(shù)據(jù);

2、終端用戶數(shù)據(jù)、運行時性能數(shù)據(jù)、物理指標(biāo)數(shù)據(jù)、服務(wù)運行指標(biāo)數(shù)據(jù)，有效關(guān)聯(lián);

3、有太多需關(guān)注的點，怎樣方便快捷地部署采集端;

4、不影響或很少影響原應(yīng)用性能。

以上也正是APM提出的需求。

一鍵式的、無干預(yù)的安裝部署與更新升級，以替代繁瑣的部署與升級;采用各個語言的底層Hook來針對性地編寫語言Agent插件，以此實現(xiàn)不修改用戶代碼而取得運行時性能數(shù)據(jù);通過主機、應(yīng)用、服務(wù)、請求的惟一標(biāo)識，來進行有效的數(shù)據(jù)關(guān)聯(lián);通過特有的數(shù)據(jù)采樣算法來達(dá)到2%以下的性能影響;一體化的數(shù)據(jù)模型，以替代密集的數(shù)據(jù)孤島。這段特征，描述的是云智慧透視寶的Smart Agent。(同樣，實現(xiàn)細(xì)節(jié)請待后文。)

 #p#

5. Analytics / Reporting

What：分析與報告

Why：簡單地講，APM對數(shù)據(jù)有兩點要求：

1、數(shù)據(jù)處理要及時，必要時候要做到實時的處理，問題可能隨時都會發(fā)生;

2、數(shù)據(jù)的分析報告要精確，大量的數(shù)據(jù)本身是無價值的，按照業(yè)務(wù)模型進行精確分析、預(yù)測才有其價值體現(xiàn)。

How：APM數(shù)據(jù)是天然的大數(shù)據(jù)，符合4V特征。因此難點幾乎與大數(shù)據(jù)處理的難點相重合：

1、數(shù)據(jù)模型語言要統(tǒng)一

2、數(shù)據(jù)存儲與查詢

3、大量復(fù)雜數(shù)據(jù)的關(guān)系建模

可以看到，云智慧透視寶架構(gòu)中Pipe Cluster的設(shè)計是對流數(shù)據(jù)的處理的核心部分，分布式、集群部署的Pipe Worker可實現(xiàn)實時的消息消費，同時基于此架構(gòu)的Data Platform與Alter Engine可實時對任意維度的數(shù)據(jù)進行分析與預(yù)警。目前數(shù)據(jù)采集量720億條/每天，共存儲200,000億條數(shù)據(jù)。(后續(xù)將對此架構(gòu)進行專文介紹。)

下圖是對比了國內(nèi)外APM行業(yè)的各廠商對以上APM模型中五個層次的認(rèn)識與支持程度：