1、簡介

應用性能管理是指對企業(yè)的關(guān)鍵業(yè)務(wù)應用進行監(jiān)測、優(yōu)化，提高企業(yè)應用的可靠性和質(zhì)量，保證用戶得到良好的服務(wù)，降低IT總擁有成本(TCO)，為企業(yè)帶來更多的商業(yè)利益。
　　應用性能管理能夠?qū)φ麄€企業(yè)的IT系統(tǒng)各個層面進行集中的性能監(jiān)控，并對有可能出現(xiàn)的性能問題進行及時、準確的分析和處理。它能輕松地從一個IT應用系統(tǒng)中找到故障點，并提供有相關(guān)解決建議或方法，從而提高整體的系統(tǒng)性能。

2、APM定義

APM發(fā)展初期，密切監(jiān)控兩組績效指標：
　　第一組性能指標定義了應用程序終端用戶所體驗的性能。 性能的一個示例是峰值負載下的平均響應時間。 該組的組件包括加載和響應時間。

• 負載是應用程序處理的事務(wù)量，例如，每秒事務(wù)數(shù)（tps），每秒請求數(shù)，每秒頁數(shù)。 在沒有被基于計算機的搜索，計算，傳輸?shù)刃枨蠹虞d的情況下，大多數(shù)應用程序都足夠快，這就是程序員在開發(fā)過程中可能無法捕獲性能問題的原因。
• 響應時間是應用程序在此類負載下響應用戶操作所需的時間。

第二組性能指標測量應用程序用于負載的計算資源，指示是否有足夠的容量來支持負載，以及性能瓶頸的可能位置。 這些數(shù)量的測量為應用建立了經(jīng)驗性能基線。 然后可以使用基線來檢測性能變化。 性能變化可與外部事件相關(guān)聯(lián)，隨后用于預測應用程序性能的未來變化。

2016年，Gartner Research將其定義更新為三個主要功能維度：

• 終端用戶體驗監(jiān)控（EUEM）已發(fā)展為數(shù)字體驗監(jiān)控（DEM）
• 新增一個新的維度：應用程序發(fā)現(xiàn)，跟蹤和診斷（ADTD）。結(jié)合了三個以前獨立的維度（應用程序拓撲[運行時架構(gòu)]發(fā)現(xiàn)和可視化，用戶定義的事務(wù)分析和應用程序組件深入研究），因為這三個維度主要集中在 問題補救方面是相互關(guān)聯(lián)的;
• 應用程序分析（AA）

3、APM框架

應用程序本身變得越來越難以管理，因為它們轉(zhuǎn)向高度分布的，多層，多元素的構(gòu)造，在許多情況下依賴于應用程序開發(fā)框架。APM概念框架旨在幫助優(yōu)先考慮首先關(guān)注的方法，以便快速實施和全面了解五維APM模型。

APM框架

1. 終端用戶體驗
   衡量從用戶請求到數(shù)據(jù)再返回的流量傳輸是捕獲最終用戶體驗（EUE）的一部分。此測量的結(jié)果稱為實時應用程序監(jiān)視（又稱自頂向下監(jiān)視），它具有被動和主動兩個組件。被動監(jiān)控 通常是使用網(wǎng)絡(luò)端口鏡像實現(xiàn)的無代理設(shè)備。主動監(jiān)控 由預定義的合成探針和Web機器人組成，用于報告系統(tǒng)可用性和業(yè)務(wù)事務(wù)（即業(yè)務(wù)方自行埋點）。
2. 應用架構(gòu)映射
   應用程序發(fā)現(xiàn)和依賴關(guān)系映射（ADDM）解決方案用于自動執(zhí)行將事務(wù)和應用程序映射到底層基礎(chǔ)架構(gòu)組件的過程。
3. 應用事務(wù)的分析
   關(guān)注用戶定義的事務(wù)或?qū)I(yè)務(wù)社區(qū)有一定意義的URL頁面定義。
4. 深度應用診斷
   深度應用診斷（DDCM）需要安裝代理，通常針對中間件，側(cè)重于Web，應用程序和消息服務(wù)器。
5. 數(shù)據(jù)分析
   獲得一組通用的度量標準以收集和報告每個應用程序非常重要，然后標準化有關(guān)數(shù)據(jù)并呈現(xiàn)應用程序性能數(shù)據(jù)的常見視圖。

4、選型：商用 or 開源 or 自建

筆者工作中開發(fā)過一個簡單的APM系統(tǒng)，故在此簡單說說假如工作中遇到領(lǐng)導要求對APM技術(shù)選型時的一些思考的方向。
　　APM系統(tǒng)的核心是數(shù)據(jù)收集，包括應用級別數(shù)據(jù)（包括APP及中間件）和機器級別數(shù)據(jù)。目前主流的開源APM系統(tǒng)的數(shù)據(jù)收集主要集中在應用級別的數(shù)據(jù)收集，典型的如OpenZipkin（當然部分開發(fā)人員覺得OpenZipkin或pinpoint等只收集了應用數(shù)據(jù)，不能算是APM；在此筆者暫將其歸為APM），稍微深入一點的，如Cat，加入了JVM監(jiān)控及簡單的告警功能。但他們都遠遠無法與商用版APM匹配，在此筆者給出個人建議：

1. 若公司是技術(shù)驅(qū)動，有一定規(guī)模，且已有完善的運維團隊，相對成熟的機器級別監(jiān)控，只需要 3. APM框架 中的1和3，則使用開源版本已足夠；且多數(shù)開源項目社區(qū)活躍，遇到問題時能夠及時得到反饋；
2. 若公司為業(yè)務(wù)、產(chǎn)品驅(qū)動的公司，不想在開發(fā)運維APM上花費過多精力，則可根據(jù)自身情況選擇商用版APM；
3. 若希望從零開始自研APM系統(tǒng)，筆者的建議是除非公司已發(fā)展的足夠規(guī)模，開源版APM確實無法滿足自身需求，再花費力氣進行相關(guān)開發(fā)工作

5、未來暢想

當公司業(yè)務(wù)有一定訪問量后，上APM將會成為必然，那么APM系統(tǒng)未來的發(fā)展方向如何呢？在此筆者提出幾點個人想法：

1. 盡可能多的收集相關(guān)數(shù)據(jù)；
2. 結(jié)合業(yè)務(wù)方線上bug，不斷完善監(jiān)控指標；
3. 結(jié)合業(yè)務(wù)方使用經(jīng)驗，提供更加直觀、高效的圖表展示；
4. 結(jié)合歷史經(jīng)驗，指導業(yè)務(wù)方排查線上問題；
5. 基于人工智能，提前發(fā)現(xiàn)業(yè)務(wù)方潛在問題（據(jù)說部分商用APM已經(jīng)實現(xiàn)）；

6、參考文獻

1. 應用性能管理
2. Application performance management