APM是指應(yīng)用程序性能管理或????應(yīng)用程序性能監(jiān)控 。您可能會(huì)爭(zhēng)辯說(shuō)它們是同一回事，或者也許管理層推斷出它們更主動(dòng)，而僅在應(yīng)用程序性能方面進(jìn)行監(jiān)控。無(wú)論哪種方式，APM都是幫助優(yōu)化和監(jiān)視應(yīng)用程序性能的必備工具。

(相關(guān)資料圖)

什么是應(yīng)用程序性能管理(APM)？

按照我的定義，APM或應(yīng)用程序性能管理在很大程度上是行業(yè)或供應(yīng)商創(chuàng)建的術(shù)語(yǔ)，用于管理或監(jiān)控代碼性能，應(yīng)用程序依賴項(xiàng)，事務(wù)時(shí)間和整體用戶體驗(yàn)的任何事情。

????維基百科  說(shuō)：自2013年上半年以來(lái)，APM進(jìn)入了技術(shù)和戰(zhàn)略競(jìng)爭(zhēng)激烈，供應(yīng)商觀點(diǎn)眾多的競(jìng)爭(zhēng)時(shí)期。這引起了市場(chǎng)的動(dòng)蕩，來(lái)自不相關(guān)背景（包括網(wǎng)絡(luò)監(jiān)控，系統(tǒng)管理，應(yīng)用程序工具和Web性能監(jiān)控）的供應(yīng)商紛紛采用APM周圍的消息傳遞。結(jié)果術(shù)語(yǔ)“ APM”已被淡化，并演變成一種概念，用于管理跨多個(gè)不同計(jì)算平臺(tái)（而不是單個(gè)市場(chǎng)）的應(yīng)用程序性能。

由于APM是與性能相關(guān)的所有事物的普遍存在的術(shù)語(yǔ)，因此某些供應(yīng)商使用該術(shù)語(yǔ)來(lái)表示完全不同的事物。APM可以涵蓋幾種不同類型的供應(yīng)商解決方案。

3種APM監(jiān)控工具:

基于應(yīng)用程序指標(biāo): 一些工具使用各種服務(wù)器和應(yīng)用程序指標(biāo)，并將其稱為APM。他們充其量只能告訴您,您的應(yīng)用程序收到了多少個(gè)請(qǐng)求，以及哪些URL可能很慢。由于他們不執(zhí)行代碼級(jí)分析，因此無(wú)法告訴您原因;

代碼級(jí)性能: ????Stackify Retrace, ????New Relic , AppDynamics和的dynaTrace是典型類型的APM產(chǎn)品，這些產(chǎn)品是基于代碼分析和事務(wù)跟蹤;

基于網(wǎng)絡(luò)的: Extrahop使用術(shù)語(yǔ)APM來(lái)表示他們根據(jù)網(wǎng)絡(luò)流量衡量應(yīng)用程序性能的能力。有一個(gè)名為NPM的整個(gè)產(chǎn)品類別，專注于此類解決方案。

其他一些工具則根據(jù)服務(wù)器和應(yīng)用程序度量標(biāo)準(zhǔn)（而非代碼級(jí)性能）進(jìn)行監(jiān)控，有時(shí)將其產(chǎn)品稱為應(yīng)用程序性能監(jiān)控解決方案。了解服務(wù)器的CPU或Web服務(wù)器的平均響應(yīng)非常重要且很有幫助，但是APM的目標(biāo)是進(jìn)一步深入。

通過(guò)利用????代碼概要分析和其他數(shù)據(jù)收集技術(shù)，應(yīng)用程序性能監(jiān)視工具 可以提供詳細(xì)的事務(wù)跟蹤。

APM就是要盡快了解"為什么"

如果要衡量Web應(yīng)用程序的性能，則解析訪問(wèn)日志并了解Web請(qǐng)求花費(fèi)的時(shí)間很簡(jiǎn)單。這將使您大致了解整體性能以及哪些頁(yè)面運(yùn)行緩慢。不幸的是，它沒(méi)有回答為什么這個(gè)關(guān)鍵問(wèn)題  。

APM解決方案的核心是了解為什么應(yīng)用程序中的事務(wù)緩慢或失敗

例如，開(kāi)發(fā)或運(yùn)維團(tuán)隊(duì)可以從該視圖立即得知他們的數(shù)據(jù)庫(kù)正在引起一些性能峰值。他們還可以利用其APM來(lái)準(zhǔn)確確定受影響的數(shù)據(jù)庫(kù)查詢和Web請(qǐng)求。

APM解決方案可以幫助快速識(shí)別常見(jiàn)的應(yīng)用程序問(wèn)題：

跟蹤整體應(yīng)用程序使用情況以了解流量高峰;

查找應(yīng)用程序相關(guān)性（包括SQL，隊(duì)列，緩存等）的速度慢或連接問(wèn)題;

識(shí)別緩慢的SQL查詢;

查找最大量和最慢的網(wǎng)頁(yè)或交易。

開(kāi)發(fā)人員關(guān)注的10個(gè)應(yīng)用性能管理功能

對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，APM實(shí)際上是關(guān)于數(shù)據(jù)的，我的意思是大量數(shù)據(jù)。但是，他們不僅需要數(shù)據(jù)，還需要從數(shù)據(jù)中獲得可行的見(jiàn)解，以便他們能夠快速找到導(dǎo)致應(yīng)用程序問(wèn)題的根本原因。

以下是其中大多數(shù)支持的一些關(guān)鍵功能。

1.每個(gè)網(wǎng)絡(luò)請(qǐng)求和交易的執(zhí)行

作為APM的核心，你必須能夠衡量應(yīng)用程序中每個(gè)Web請(qǐng)求和事務(wù)的性能。然后，你可以使用它來(lái)了解訪問(wèn)最多的請(qǐng)求，訪問(wèn)最慢的請(qǐng)求以及應(yīng)添加到待辦事項(xiàng)中以改進(jìn)的請(qǐng)求。

不過(guò)，了解每個(gè)Web請(qǐng)求的性能只是一個(gè)開(kāi)始。您可能會(huì)從Web服務(wù)器訪問(wèn)日志中獲得該信息。真正的關(guān)鍵是理解原因。

2.代碼級(jí)性能分析

如果你想了解為什么應(yīng)用程序運(yùn)行緩慢，引發(fā)錯(cuò)誤或出現(xiàn)奇怪的錯(cuò)誤，則必須深入到代碼級(jí)別。知道某個(gè)Web請(qǐng)求不起作用很重要，而且實(shí)際上很容易。弄清楚為什么它不起作用很難，那就很難了。

通過(guò)跟蹤應(yīng)用程序一直到????代碼級(jí)別的工作，您可以潛在地獲得有關(guān)正在發(fā)生的事情的更多見(jiàn)解：

您的代碼中哪些關(guān)鍵方法甚至被調(diào)用？

哪些方法比較慢？

您的應(yīng)用是否由于JIT，垃圾收集等原因而運(yùn)行緩慢？

調(diào)用了什么依賴項(xiàng)?

3. 所有應(yīng)用程序依賴的使用和性能，如數(shù)據(jù)庫(kù)、web服務(wù)、緩存等

為什么您的應(yīng)用程序運(yùn)行緩慢的原因通常歸結(jié)為流量激增或????應(yīng)用程序依賴項(xiàng)之一出現(xiàn)問(wèn)題。

這些是常見(jiàn)類型的問(wèn)題：

特定的????SQL查詢速度很慢;

SQL數(shù)據(jù)庫(kù)服務(wù)器已關(guān)閉;

外部HTTP Web服務(wù)調(diào)用失敗;

云上共同租戶復(fù)雜的環(huán)境造成的問(wèn)題。

舉一個(gè)例子，我們最近在訪問(wèn)Hubspot的API時(shí)遇到了一些問(wèn)題。他們限制了我們，我們唯一會(huì)知道的方法是跟蹤所有異常，并在APM中看到那些受影響的交易也失敗了。

4.各個(gè)Web請(qǐng)求或交易的詳細(xì)跟蹤

解決生產(chǎn)中的問(wèn)題非常困難。????事務(wù)跟蹤使您能夠查看有關(guān)代碼中正在發(fā)生的確切變化以及它們?nèi)绾斡绊懹脩舻脑敿?xì)信息，從而使此過(guò)程變得更加容易。

跟蹤可以包含以下類型的數(shù)據(jù)：

Web請(qǐng)求信息，例如URL等；

用戶是誰(shuí)；

您的代碼調(diào)用了哪些依賴項(xiàng)（SQL，緩存，HTTP調(diào)用等）；

記錄SQL語(yǔ)句;

應(yīng)用錯(cuò)誤;

代碼中的關(guān)鍵方法。

在一條軌跡線索中看到所有這些數(shù)據(jù)可能會(huì)導(dǎo)致短路，從而不得不嘗試重現(xiàn)QA中的問(wèn)題。使用APM解決方案收集詳細(xì)信息跟蹤，幾乎可以立即找出根本原因。

5.基本的服務(wù)器監(jiān)控和指標(biāo)，例如CPU，內(nèi)存等

出現(xiàn)應(yīng)用程序問(wèn)題的原因很多。得益于虛擬化和云技術(shù)，如今服務(wù)器故障的情況已不那么普遍。但是，它仍然會(huì)發(fā)生，這是你仍需要監(jiān)控的事情。監(jiān)控????服務(wù)器CPU和內(nèi)存等內(nèi)容也很重要。許多現(xiàn)代Web應(yīng)用程序通常不受CPU限制，但是它們?nèi)匀豢梢允褂么罅緾PU，這是在云上自動(dòng)擴(kuò)展應(yīng)用程序的有用指標(biāo)。

6.應(yīng)用程序框架指標(biāo)，例如性能計(jì)數(shù)器，JMX MBean等

服務(wù)器指標(biāo)（例如CPU和內(nèi)存）很有趣，但是對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，應(yīng)用程序指標(biāo)對(duì)于真正的應(yīng)用程序性能監(jiān)控可能更有價(jià)值。開(kāi)發(fā)人員需要監(jiān)控諸如????垃圾收集，請(qǐng)求隊(duì)列，事務(wù)量，頁(yè)面加載時(shí)間等內(nèi)容的指標(biāo)。開(kāi)發(fā)人員可以監(jiān)控各種????Windows性能計(jì)數(shù)器和????JMX MBean。監(jiān)控Redis，????Elasticsearch，SQL和其他服務(wù)等關(guān)鍵指標(biāo)也很關(guān)鍵。

7.開(kāi)發(fā)團(tuán)隊(duì)或企業(yè)創(chuàng)建的自定義應(yīng)用程序指標(biāo)

標(biāo)準(zhǔn)服務(wù)器和????應(yīng)用程序指標(biāo)對(duì)于監(jiān)控應(yīng)用程序非常有幫助。但是，通過(guò)創(chuàng)建和監(jiān)視自己的自定義指標(biāo)，您可能會(huì)獲得更多價(jià)值。在Stackify，我們使用它們來(lái)執(zhí)行諸如監(jiān)控每分鐘有多少條日志消息PUSH給我們或處理消息離開(kāi)隊(duì)列需要多長(zhǎng)時(shí)間的事情。這些類型的自定義指標(biāo)易于創(chuàng)建，對(duì)于????監(jiān)視應(yīng)用程序性能非常有用。

8.應(yīng)用程序日志數(shù)據(jù)

每當(dāng)生產(chǎn)中出現(xiàn)問(wèn)題時(shí)，您會(huì)聽(tīng)到開(kāi)發(fā)人員說(shuō)的第一件事是“將日志發(fā)送給我”。部署應(yīng)用程序后，日志數(shù)據(jù)通常是開(kāi)發(fā)人員的耳目。開(kāi)發(fā)人員需要通過(guò)集中式日志記錄解決方案（如日志管理產(chǎn)品）來(lái)訪問(wèn)其日志。幸運(yùn)的是，????日志管理是????Retrace中包含的APM功能。大多數(shù)APM解決方案都不支持開(kāi)發(fā)人員想要查看的日志！

9.應(yīng)用錯(cuò)誤

我們想要的最后一件事是讓用戶與我們聯(lián)系，并告訴我們，我們的應(yīng)用程序正在給他們提供錯(cuò)誤或正在崩潰。作為開(kāi)發(fā)人員，我們需要隨時(shí)注意這種情況，并不斷地為他們提供注意。

錯(cuò)誤是發(fā)現(xiàn)應(yīng)用程序問(wèn)題的第一道防線。在客戶打電話告訴我們之前，我們需要查找并修復(fù)錯(cuò)誤，或者至少是對(duì)錯(cuò)誤的了解，因?yàn)榭蛻舭l(fā)現(xiàn)錯(cuò)誤問(wèn)題，他們不會(huì)告訴我們，只會(huì)選擇新的商家，離開(kāi)你們這糟糕體驗(yàn)的應(yīng)用 or 產(chǎn)品。

出色的????錯(cuò)誤跟蹤，報(bào)告和警報(bào)對(duì)于應(yīng)用程序性能管理系統(tǒng)中的開(kāi)發(fā)人員絕對(duì)至關(guān)重要。我強(qiáng)烈建議為新的異常以及監(jiān)控總體錯(cuò)誤率設(shè)置警報(bào)。每當(dāng)您對(duì)生產(chǎn)進(jìn)行新的部署時(shí)，您都應(yīng)該觀察錯(cuò)誤儀表板，以查看是否出現(xiàn)了任何新問(wèn)題。奇怪的是，您會(huì)發(fā)現(xiàn)一些新類型的錯(cuò)誤，然后可以快速識(shí)別并修復(fù)這些錯(cuò)誤。

10. 真實(shí)用戶監(jiān)視（RUM）

了解服務(wù)器端應(yīng)用程序的性能很重要。但是，當(dāng)今的應(yīng)用程序使用了太多的JavaScript，因此還必須監(jiān)控瀏覽器完全加載和呈現(xiàn)你的網(wǎng)頁(yè)所花費(fèi)的時(shí)間。一個(gè)簡(jiǎn)單的JavaScript錯(cuò)誤或加載緩慢的JavaScript文件可能會(huì)完全破壞您的應(yīng)用程序。????實(shí)時(shí)用戶監(jiān)控（RUM）是APM的另一個(gè)重要功能，開(kāi)發(fā)人員需要全面監(jiān)視其應(yīng)用程序。

APM市場(chǎng)和價(jià)格

APM市場(chǎng)最早在美國(guó)興起，作為傳統(tǒng)軟件業(yè)務(wù)，一直為大型軟件公司壟斷，在1998-2008年期間，只有像CA、IBM、BMC、微軟這樣大玩家。但是這種局面在2008年得到改變，隨著SaaS服務(wù)的普及，出現(xiàn)了New Relic、AppDynamics和Compuware這類新興IT企業(yè)，以SaaS方式進(jìn)入APM市場(chǎng)。

2008年可以看作APM的SaaS元年。雖然APM市場(chǎng)前景仍寬廣，但是在大客戶已經(jīng)為先行者壟斷的情況下，新興的IT運(yùn)維企業(yè)只能選擇中小型企業(yè)市場(chǎng)，New Relic目標(biāo)客戶就是小型企業(yè)和個(gè)人開(kāi)發(fā)者。

綜合來(lái)看，目前美國(guó)市場(chǎng)格局是，綜合軟件公司已占領(lǐng)大客戶資源，新興企業(yè)在邊緣尋找機(jī)會(huì)。

APM有兩種模式，一種是SaaS模式，典型代表是New Relic、AppDynamics、Stackify這類新興企業(yè)；另一種私有部署模式，以CA、IBM、BMC、微軟這類傳統(tǒng)軟件公司為主。兩種模式的客單價(jià)、銷售方式、商業(yè)模式并不相同，前者是SaaS模式，后者更類似于傳統(tǒng)軟件行業(yè)。

國(guó)內(nèi)主流APM廠商主要采用第二種模式，也就是大客戶的私有部署。因此，可以作為對(duì)標(biāo)研究的行業(yè)包括APM、CDN、傳統(tǒng)軟件公司。

其中最有代表性公司是 New Relic（NSDQ:NEWR）、用友網(wǎng)絡(luò)（SH:600588）和網(wǎng)宿科技（SZ:300017）三家公司，分別代表APM市場(chǎng)、軟件服務(wù)和可比行業(yè)。

而國(guó)內(nèi)知名的創(chuàng)業(yè)APM公司包括基調(diào)(聽(tīng)云)、云智慧(透視寶)、博睿、OneAPM， 但是OneAPM基本套現(xiàn)走了，沒(méi)有什么價(jià)值了，自從16年登錄新三板，何曉陽(yáng)都套現(xiàn)去搞區(qū)塊鏈lambda項(xiàng)目了。

開(kāi)源的APM項(xiàng)目主要包括????PinPoint、????skywalking、????zipkin、美團(tuán)的????cat, 相對(duì)于傳統(tǒng)的監(jiān)控軟件（Zabbix之流）的區(qū)別，APM跟關(guān)注在對(duì)于系統(tǒng)內(nèi)部執(zhí)行、系統(tǒng)間調(diào)用的性能瓶頸分析，這樣更有利于定位到問(wèn)題的具體原因，而不僅僅像傳統(tǒng)監(jiān)控軟件一樣只提供一些零散的監(jiān)控點(diǎn)和指標(biāo)，就算告警了也不知道問(wèn)題是出在哪里。

傳統(tǒng)上，應(yīng)用程序性能管理工具是昂貴的奢侈品，只有大型IT企業(yè)才能負(fù)擔(dān)得起。許多APM供應(yīng)商仍然迎合大型企業(yè)的需求，每臺(tái)服務(wù)器每年仍收取2000$- 4000$。

大多數(shù)APM解決方案的配置和使用都非常復(fù)雜。如此之多，以至于開(kāi)發(fā)團(tuán)隊(duì)甚至都不使用它們。它們最終成為昂貴的交通信號(hào)燈和儀表板。一些供應(yīng)商非常重視????使他們的產(chǎn)品價(jià)格適中  并且非常易于使用，因此各種規(guī)模的開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)都可以使用它們, 而Stackify推出的產(chǎn)品 ????Retrace每月僅需10$。

國(guó)內(nèi)的APM廠商基本SAAS不掙錢(qián)了，基本用戶也比較少，有用戶的話也基本都是移動(dòng)端和RUM的需求，國(guó)內(nèi)環(huán)境決定的，愿意花錢(qián)的甲方都很介意數(shù)據(jù)放到云上，一般都喜歡采用私有化、私有云的方式，以項(xiàng)目的形式采購(gòu)和采用APM產(chǎn)品，而不愿意花錢(qián)的客戶基本都是采用開(kāi)源產(chǎn)品 or 自研構(gòu)建。