New Relic性能監控（二）應用監控APM

New Relic性能監控（二）應用監控APM

2018-04-12 琅琊書生

本系列文章基於公司使用New Relic的經驗，鑑於國內較少有這方面的文章，所以把我工做中瞭解到的知識分享給你們，但願能夠給須要的朋友帶來幫助。

上期文章咱們對New Relic的監控產品組成作了總體的介紹，今天咱們主要來介紹下服務端應用監控產品New Relic APM。

什麼是APM

APM全稱是Application Performance Management，即應用程序性能監控。APM能夠全方位監控系統運行狀態，可以讓咱們獲取詳細的數據，包括系統響應時間，吞吐量，定位緩慢的事務，找到應用的瓶頸。

APM原理

New Relic APM目前支持如下七種語言: Ruby, Java, Node.js, PHP, .NET, Python, Go，有興趣的朋友能夠在官方網站查到如何啓用New Relic APM。這裏以java爲例。New Relic提供了一個java agent的jar包。在應用程序啓動時，指定加載該agent，並作好相應的設置，New Relic就能夠監控你的java應用，並按期將收集到數據上報到New Relic的服務器。

能夠看到，New Relic這種非侵入式的應用監控很是易於使用。事實上，除了Go語言以外，其餘支持的六種語言都是以這種agent的方式實現監控。Go比較特殊。因爲Go是編譯成本地代碼（不一樣於java的字節碼之類有中間代碼存在的語言），因此須要使用者使用New Relic提供的Go SDK，在代碼中自行植入監控代碼。

APM並非一個新鮮的東西，早在不少年前就已經存在。那麼是什麼使得New Relic勝出呢？答案是Saas。近幾年雲計算的發展迅速，愈來愈多的應用正在開始以服務的方式提供。早先的APM使用很是不便，用戶須要本地部署服務器用以存放數據，被監控的應用要保證正確的配置以便可以將數據上傳；還須要組建數據分析團隊，針對收集到的數據，結合應用的業務場景做出具體的分析工做。這些工做都要耗費不少的資源。New Relic把這一切簡化，以服務的方式提供APM功能。用戶只須要加載對應語言的agent，就可以自動監控應用，上報數據，分析結果等。全部的工做都有New Relic提供的工具來完成。

圖 1: New Relic APM工做模式

APM採集的數據分析

圖二爲New Relic上某一應用的APM主頁。

圖2: 某一應用的APM頁面

該頁面分爲兩大塊：左邊的菜單欄和右側的圖表。
左邊側邊欄分爲三個組，分別爲監控數據，事件和報告。

監控數據是New Relic收集到的數據彙總。New Relic能夠檢測到應用與其餘服務之間的關聯和依賴關係，包括數據庫和外部依賴。這裏有個很是重要的概念：事務（Transaction)。這裏的事務並不是是數據庫事務，而是應用對一次請求的處理。從接到請求到響應處理完成的過程爲稱爲一次事務。New Relic可以精確的監控到一次事務中耗費在各個階段的時間。在圖二中，黃色部分爲數據庫處理時間，淺藍色爲JVM中耗費的時間。經過這些數據咱們能清楚的瞭解不一樣的事務在處理過程當中的瓶頸所在。好比有的事務在數據庫端要耗費大量時間，意味着有可能須要做優化查詢。

New Relic還能夠列出每一個事務耗費的時間，圖三爲最爲耗時的事務列表：

圖三：事務列表

各事務按所耗費的時間多少排序，讓咱們可以瞭解最爲耗費時間的處理流程，尋找能夠優化的區域。每個事務都有很是詳細的數據。圖四爲某一事務的詳細時間話費統計。

圖四:精細的事務時間耗費統計

圖中能夠看出，該事務在數據庫查詢操做上耗費了大量的時間（圖中棕色部分）。而下方的表格則給出了具體的數據，數據庫查詢 Postgres xyf_size_offset select 是耗時最久的部分，佔整個事務一半多的時間。那麼整個應用全部的數據庫操做在性能表現上是什麼狀況呢？圖五就是這方面的統計。

圖五：數據庫訪問性能統計

咱們發現，剛纔的那個數據庫操做不只是那個事務中性能最差的，在全部的數據庫操做中都是耗時最久的。
針對java應用，APM還提供JVM性能監控數據，包括內存使用，線程數等等。

告警

APM支持告警設置。用戶能夠設置監控指標和指望的性能表現。一旦指標在必定時間內未能達到要求，則自動發出告警。告警能夠發送到郵箱或者其餘一些即時通信工具，使得運維人員能及時獲知系統異常狀況。

圖六：告警

總結

New Relic APM使用方便，數據全面，數據展現詳細，很是值得一試。