<form id="dlljd"></form>
        <address id="dlljd"><address id="dlljd"><listing id="dlljd"></listing></address></address>

        <em id="dlljd"><form id="dlljd"></form></em>

          <address id="dlljd"></address>
            <noframes id="dlljd">

              聯系我們 - 廣告服務 - 聯系電話:
              您的當前位置: > 關注 > > 正文

              【獨家】什么是APM?什么是應用程序性能管理(APM)?

              來源:CSDN 時間:2023-03-15 15:36:56

              APM是指應用程序性能管理或????應用程序性能監控 。您可能會爭辯說它們是同一回事,或者也許管理層推斷出它們更主動,而僅在應用程序性能方面進行監控。無論哪種方式,APM都是幫助優化和監視應用程序性能的必備工具。


              (相關資料圖)

              什么是應用程序性能管理(APM)?

              按照我的定義,APM或應用程序性能管理在很大程度上是行業或供應商創建的術語,用于管理或監控代碼性能,應用程序依賴項,事務時間和整體用戶體驗的任何事情。

              ????維基百科  說:自2013年上半年以來,APM進入了技術和戰略競爭激烈,供應商觀點眾多的競爭時期。這引起了市場的動蕩,來自不相關背景(包括網絡監控,系統管理,應用程序工具和Web性能監控)的供應商紛紛采用APM周圍的消息傳遞。結果術語“ APM”已被淡化,并演變成一種概念,用于管理跨多個不同計算平臺(而不是單個市場)的應用程序性能。

              由于APM是與性能相關的所有事物的普遍存在的術語,因此某些供應商使用該術語來表示完全不同的事物。APM可以涵蓋幾種不同類型的供應商解決方案。

              3種APM監控工具:

              基于應用程序指標: 一些工具使用各種服務器和應用程序指標,并將其稱為APM。他們充其量只能告訴您,您的應用程序收到了多少個請求,以及哪些URL可能很慢。由于他們不執行代碼級分析,因此無法告訴您原因;

              代碼級性能: ????Stackify Retrace, ????New Relic , AppDynamics和的dynaTrace是典型類型的APM產品,這些產品是基于代碼分析和事務跟蹤;

              基于網絡的: Extrahop使用術語APM來表示他們根據網絡流量衡量應用程序性能的能力。有一個名為NPM的整個產品類別,專注于此類解決方案。

              其他一些工具則根據服務器和應用程序度量標準(而非代碼級性能)進行監控,有時將其產品稱為應用程序性能監控解決方案。了解服務器的CPU或Web服務器的平均響應非常重要且很有幫助,但是APM的目標是進一步深入。

              通過利用????代碼概要分析和其他數據收集技術,應用程序性能監視工具 可以提供詳細的事務跟蹤

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

              如果要衡量Web應用程序的性能,則解析訪問日志并了解Web請求花費的時間很簡單。這將使您大致了解整體性能以及哪些頁面運行緩慢。不幸的是,它沒有回答為什么這個關鍵問題  。

              APM解決方案的核心是了解為什么應用程序中的事務緩慢或失敗

              例如,開發或運維團隊可以從該視圖立即得知他們的數據庫正在引起一些性能峰值。他們還可以利用其APM來準確確定受影響的數據庫查詢和Web請求。

              APM解決方案可以幫助快速識別常見的應用程序問題:

              跟蹤整體應用程序使用情況以了解流量高峰;

              查找應用程序相關性(包括SQL,隊列,緩存等)的速度慢或連接問題;

              識別緩慢的SQL查詢;

              查找最大量和最慢的網頁或交易。

              開發人員關注的10個應用性能管理功能

              對于開發人員來說,APM實際上是關于數據的,我的意思是大量數據。但是,他們不僅需要數據,還需要從數據中獲得可行的見解,以便他們能夠快速找到導致應用程序問題的根本原因。

              以下是其中大多數支持的一些關鍵功能。

              1.每個網絡請求和交易的執行

              作為APM的核心,你必須能夠衡量應用程序中每個Web請求和事務的性能。然后,你可以使用它來了解訪問最多的請求,訪問最慢的請求以及應添加到待辦事項中以改進的請求。

              不過,了解每個Web請求的性能只是一個開始。您可能會從Web服務器訪問日志中獲得該信息。真正的關鍵是理解原因。

              2.代碼級性能分析

              如果你想了解為什么應用程序運行緩慢,引發錯誤或出現奇怪的錯誤,則必須深入到代碼級別。知道某個Web請求不起作用很重要,而且實際上很容易。弄清楚為什么它不起作用很難,那就很難了。

              通過跟蹤應用程序一直到????代碼級別的工作,您可以潛在地獲得有關正在發生的事情的更多見解:

              您的代碼中哪些關鍵方法甚至被調用?

              哪些方法比較慢?

              您的應用是否由于JIT,垃圾收集等原因而運行緩慢?

              調用了什么依賴項?

              3. 所有應用程序依賴的使用和性能,如數據庫、web服務、緩存等

              為什么您的應用程序運行緩慢的原因通常歸結為流量激增或????應用程序依賴項之一出現問題。

              這些是常見類型的問題:

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

              SQL數據庫服務器已關閉;

              外部HTTP Web服務調用失敗;

              云上共同租戶復雜的環境造成的問題。

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

              4.各個Web請求或交易的詳細跟蹤

              解決生產中的問題非常困難。????事務跟蹤使您能夠查看有關代碼中正在發生的確切變化以及它們如何影響用戶的詳細信息,從而使此過程變得更加容易。

              跟蹤可以包含以下類型的數據:

              Web請求信息,例如URL等;

              用戶是誰;

              您的代碼調用了哪些依賴項(SQL,緩存,HTTP調用等);

              記錄SQL語句;

              應用錯誤;

              代碼中的關鍵方法。

              在一條軌跡線索中看到所有這些數據可能會導致短路,從而不得不嘗試重現QA中的問題。使用APM解決方案收集詳細信息跟蹤,幾乎可以立即找出根本原因。

              5.基本的服務器監控和指標,例如CPU,內存等

              出現應用程序問題的原因很多。得益于虛擬化和云技術,如今服務器故障的情況已不那么普遍。但是,它仍然會發生,這是你仍需要監控的事情。監控????服務器CPU和內存等內容也很重要。許多現代Web應用程序通常不受CPU限制,但是它們仍然可以使用大量CPU,這是在云上自動擴展應用程序的有用指標。

              6.應用程序框架指標,例如性能計數器,JMX MBean等

              服務器指標(例如CPU和內存)很有趣,但是對于開發人員來說,應用程序指標對于真正的應用程序性能監控可能更有價值。開發人員需要監控諸如????垃圾收集,請求隊列,事務量,頁面加載時間等內容的指標。開發人員可以監控各種????Windows性能計數器和????JMX MBean。監控Redis,????Elasticsearch,SQL和其他服務等關鍵指標也很關鍵。

              7.開發團隊或企業創建的自定義應用程序指標

              標準服務器和????應用程序指標對于監控應用程序非常有幫助。但是,通過創建和監視自己的自定義指標,您可能會獲得更多價值。在Stackify,我們使用它們來執行諸如監控每分鐘有多少條日志消息PUSH給我們或處理消息離開隊列需要多長時間的事情。這些類型的自定義指標易于創建,對于????監視應用程序性能非常有用。

              8.應用程序日志數據

              每當生產中出現問題時,您會聽到開發人員說的第一件事是“將日志發送給我”。部署應用程序后,日志數據通常是開發人員的耳目。開發人員需要通過集中式日志記錄解決方案(如日志管理產品)來訪問其日志。幸運的是,????日志管理是????Retrace中包含的APM功能。大多數APM解決方案都不支持開發人員想要查看的日志!

              9.應用錯誤

              我們想要的最后一件事是讓用戶與我們聯系,并告訴我們,我們的應用程序正在給他們提供錯誤或正在崩潰。作為開發人員,我們需要隨時注意這種情況,并不斷地為他們提供注意。

              錯誤是發現應用程序問題的第一道防線。在客戶打電話告訴我們之前,我們需要查找并修復錯誤,或者至少是對錯誤的了解,因為客戶發現錯誤問題,他們不會告訴我們,只會選擇新的商家,離開你們這糟糕體驗的應用 or 產品。

              出色的????錯誤跟蹤,報告和警報對于應用程序性能管理系統中的開發人員絕對至關重要。我強烈建議為新的異常以及監控總體錯誤率設置警報。每當您對生產進行新的部署時,您都應該觀察錯誤儀表板,以查看是否出現了任何新問題。奇怪的是,您會發現一些新類型的錯誤,然后可以快速識別并修復這些錯誤。

              10. 真實用戶監視(RUM)

              了解服務器端應用程序的性能很重要。但是,當今的應用程序使用了太多的JavaScript,因此還必須監控瀏覽器完全加載和呈現你的網頁所花費的時間。一個簡單的JavaScript錯誤或加載緩慢的JavaScript文件可能會完全破壞您的應用程序。????實時用戶監控(RUM)是APM的另一個重要功能,開發人員需要全面監視其應用程序。

              APM市場和價格

              APM市場最早在美國興起,作為傳統軟件業務,一直為大型軟件公司壟斷,在1998-2008年期間,只有像CA、IBM、BMC、微軟這樣大玩家。但是這種局面在2008年得到改變,隨著SaaS服務的普及,出現了New Relic、AppDynamics和Compuware這類新興IT企業,以SaaS方式進入APM市場。

              2008年可以看作APM的SaaS元年。雖然APM市場前景仍寬廣,但是在大客戶已經為先行者壟斷的情況下,新興的IT運維企業只能選擇中小型企業市場,New Relic目標客戶就是小型企業和個人開發者。

              綜合來看,目前美國市場格局是,綜合軟件公司已占領大客戶資源,新興企業在邊緣尋找機會。

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

              國內主流APM廠商主要采用第二種模式,也就是大客戶的私有部署。因此,可以作為對標研究的行業包括APM、CDN、傳統軟件公司。

              其中最有代表性公司是 New Relic(NSDQ:NEWR)、用友網絡(SH:600588)和網宿科技(SZ:300017)三家公司,分別代表APM市場、軟件服務和可比行業。

              而國內知名的創業APM公司包括基調(聽云)、云智慧(透視寶)、博睿、OneAPM, 但是OneAPM基本套現走了,沒有什么價值了,自從16年登錄新三板,何曉陽都套現去搞區塊鏈lambda項目了。

              開源的APM項目主要包括????PinPoint、????skywalking、????zipkin、美團的????cat, 相對于傳統的監控軟件(Zabbix之流)的區別,APM跟關注在對于系統內部執行、系統間調用的性能瓶頸分析,這樣更有利于定位到問題的具體原因,而不僅僅像傳統監控軟件一樣只提供一些零散的監控點和指標,就算告警了也不知道問題是出在哪里。

              傳統上,應用程序性能管理工具是昂貴的奢侈品,只有大型IT企業才能負擔得起。許多APM供應商仍然迎合大型企業的需求,每臺服務器每年仍收取2000$- 4000$。

              大多數APM解決方案的配置和使用都非常復雜。如此之多,以至于開發團隊甚至都不使用它們。它們最終成為昂貴的交通信號燈和儀表板。一些供應商非常重視????使他們的產品價格適中  并且非常易于使用,因此各種規模的開發和運營團隊都可以使用它們, 而Stackify推出的產品 ????Retrace每月僅需10$。

              國內的APM廠商基本SAAS不掙錢了,基本用戶也比較少,有用戶的話也基本都是移動端和RUM的需求,國內環境決定的,愿意花錢的甲方都很介意數據放到云上,一般都喜歡采用私有化、私有云的方式,以項目的形式采購和采用APM產品,而不愿意花錢的客戶基本都是采用開源產品 or 自研構建。

              責任編輯:

              標簽: 應用程序 開發人員

              相關推薦:

              精彩放送:

              新聞聚焦
              Top 中文字幕在线观看亚洲日韩