前   言

最近幾年APM是個網(wǎng)紅詞匯，但是大家對APM的認知還有一些誤區(qū)，人們普遍認為APM是解決應用故障的利器。當業(yè)務系統(tǒng)被投訴緩慢或者內(nèi)存泄露被迫不斷重啟等問題出現(xiàn)時，運營商就快速找一個APM廠商，要求幫忙快速定位問題，如果問題解決了說明產(chǎn)品有價值，但由于問題已經(jīng)解決便不再購買，如果沒有解決則認為APM沒有用更不再購買了！

但是要知道，解決應用生產(chǎn)環(huán)境中的各種性能故障是APM的絕招之一，如果只是將APM應用在這個范疇，那真是殺雞用了牛刀呀！今天我們就和大家聊聊，APM還有哪些價值。

我們認為，APM還有下面四個方面的核心價值：

1.    動態(tài)業(yè)務系統(tǒng)架構(gòu)的梳理分析

2.    關鍵業(yè)務的篩選

3.    系統(tǒng)故障快速鎖定排查

4.    全量數(shù)據(jù)多維度智能關聯(lián)分析

1.動態(tài)業(yè)務系統(tǒng)架構(gòu)分析

某電力客戶的部分業(yè)務請求需要加載幾分鐘才能出來，審批一個列表經(jīng)常喝完一杯水都還沒有完成。經(jīng)過多次不同環(huán)境、不同時段測試發(fā)現(xiàn)該狀況是一個常態(tài)，我們從URL請求架構(gòu)層出發(fā)研究調(diào)用系統(tǒng)方法量和訪問數(shù)據(jù)庫量進行分析，發(fā)現(xiàn)單次URL請求調(diào)用數(shù)據(jù)庫達到幾百次，頻繁調(diào)用數(shù)據(jù)庫導致執(zhí)行效率降低，增加URL請求的處理時間，通過在業(yè)務系統(tǒng)增加緩存機制大大提升了業(yè)務請求的效率。

APM必須具備系統(tǒng)架構(gòu)的分析能力，架構(gòu)分析可從兩個維度分析，分別是：業(yè)務系統(tǒng)運行狀態(tài)和各組件之間的數(shù)據(jù)對比。下面我就給大家說說兩個維度應該分析的內(nèi)容：
   （1）、 業(yè)務系統(tǒng)運行狀態(tài)。架構(gòu)合理的業(yè)務系統(tǒng)數(shù)據(jù)異常只是偶發(fā)性事件，持續(xù)發(fā)生數(shù)據(jù)異常均為架構(gòu)不合理造成的。

• 業(yè)務請求的緩慢率。緩慢率高一般是由多個業(yè)務緩慢引起，多個業(yè)務同時發(fā)生緩慢只有兩種情況，一是網(wǎng)絡原因，二就是系統(tǒng)架構(gòu)不合理。

• 系統(tǒng)異常的發(fā)生次數(shù)。系統(tǒng)異常為偶發(fā)性事件，若持續(xù)發(fā)生大量的系統(tǒng)異常，表明系統(tǒng)資源和方法存在不合理的使用。

• 業(yè)務錯誤的發(fā)生次數(shù)。業(yè)務請求出現(xiàn)大量的業(yè)務錯誤，肯定是URL請求與處理過程中存在問題，是否對所有場景都支持。

• FGC的發(fā)生頻率。頻繁發(fā)生FGC的原因多種多樣，通常情況下是因為系統(tǒng)突然產(chǎn)生大量垃圾，導致系統(tǒng)觸發(fā)FGC無法進行其他任務。

• 內(nèi)存及CPU的利用率。內(nèi)存與CPU是否長期利用率較高或多次發(fā)生內(nèi)存占滿與CPU占用的情況。

   （2）、各組件之間的數(shù)據(jù)對比。

• 前后與后端的調(diào)用量和響應時間的對比。前端調(diào)用次數(shù)與后端調(diào)用次數(shù)比例越大表明結(jié)構(gòu)越不合理，前端響應時間與后端響應時間對比分析耗時比例。

• URL請求與SQL調(diào)用的對比。URL請求次數(shù)與SQL調(diào)用次數(shù)的比例，平均每次請求觸發(fā)多少次SQL調(diào)用，架構(gòu)不合理在數(shù)據(jù)對比下顯露無遺。如下圖，1次URL平均有40多次的SQL調(diào)用，架構(gòu)上就不是很合理。

• 業(yè)務系統(tǒng)中業(yè)務組的數(shù)量。業(yè)務請求組有多少，業(yè)務請求有沒有進行多合一設計或者一分多設計。

• 業(yè)務請求報文與方法。業(yè)務請求報文的格式（XML或JSON），主要使用的請求方法格式（POST或GET），這樣看到系統(tǒng)的開發(fā)周期和安全性隱患等。

2.智能鎖定關鍵業(yè)務能力

每個應用少則擁有幾千個不同的URL，多則擁有上萬個URL，每天的請求量都在十萬級、百萬級、千萬級以上，這么多不同的URL和海量URL請求數(shù)據(jù)，如何從中準確找到用價值的URL并對這些關鍵的業(yè)務請求進行布控即成為關鍵。

APM必須要擁有對URL智能分組統(tǒng)計的能力，并對自動分布的URL進行任意參數(shù)的TOP對比。如：請求次數(shù)最多的10個URL、相應時間最長的10個URL、錯誤率最高的10個URL、失敗率最高的10個URL。在找到關鍵的URL后可以快速標記并進行自定義命名。對海量的URL請求可以做到自動標記和命名，并對重要業(yè)務進行自動標記和自定義命名。智能鎖定關鍵交易后可對關鍵交易進行精準優(yōu)化和唯一策略的精準告警等。

但是常常技術(shù)指標上發(fā)現(xiàn)的URL經(jīng)常是助攻型業(yè)務請求，不是真正的核心業(yè)務，這時候就需要開發(fā)人員、業(yè)務人員和工具一起快速確定關鍵業(yè)務。 

3.系統(tǒng)故障快速鎖定排查能力

伴隨著各系統(tǒng)微服務化的演進，服務數(shù)量、機器規(guī)模的不斷增長，線上環(huán)境也變得日益復雜，工程師們每天都會面臨著這些苦惱：

1.線上系統(tǒng)出現(xiàn)故障時無法第一時間感知；

2.面對線上系統(tǒng)產(chǎn)生的海量日志，排查故障時一籌莫展；

3.系統(tǒng)內(nèi)部及系統(tǒng)間的調(diào)用鏈路產(chǎn)生故障時難以定位；

……

線上應用的性能問題和異常錯誤已經(jīng)成為開發(fā)人員和運維人員最大的挑戰(zhàn)，而排查這類問題往往需要幾個小時甚至幾天的時間，效率低下且嚴重影響了業(yè)務發(fā)展。

       高效運維APM必須要具備一項能力：要做到實時告警，針對應用層、服務器層、單業(yè)務層、用戶層等多層級多維度的告警機制，做到系統(tǒng)故障第一時間感知。在告警的同時要對故障進行記錄，標記故障位置，在故障排查時查看發(fā)生時的系統(tǒng)資源狀態(tài)、交易鏈調(diào)用、故障信息、組件狀態(tài)等做到還原故障現(xiàn)場。

4.全量數(shù)據(jù)多維度關聯(lián)分析能力

APM監(jiān)控到的海量數(shù)據(jù)如果只是用來故障排查，那就大大降低了數(shù)據(jù)的價值。如何讓APM監(jiān)控的數(shù)據(jù)發(fā)揮更大價值呢？這個就需要APM擁有全量數(shù)據(jù)多維度關聯(lián)分析的能力，包括任一時段任意維度的數(shù)據(jù)環(huán)比分析，不同組件數(shù)據(jù)間的智能關聯(lián)分析。如：今天與昨天的數(shù)據(jù)對比，本周與上周的數(shù)據(jù)對比，URL請求與數(shù)據(jù)庫調(diào)用比例，前端與后端相應時間對比等。

APM只解決故障的時代已經(jīng)過去

數(shù)據(jù)在未來企業(yè)發(fā)展中舉足輕重，人們常說“得數(shù)據(jù)者得天下”。APM一直以來的職責都是依靠不斷獲取數(shù)據(jù)來完成，隨著APM的不斷發(fā)展，所獲取的數(shù)據(jù)也越來越多、越來越全面，數(shù)據(jù)的不斷積累使得APM的使命不斷豐富。新一代的APM要向應用業(yè)務性能管理邁進，強調(diào)業(yè)務分析能力，幫助企業(yè)進行業(yè)務梳理，抓住業(yè)務變化趨勢背后的需求變化，用業(yè)務數(shù)據(jù)、智能分析為企業(yè)創(chuàng)新、創(chuàng)收提供支撐。