摘要:左邊側(cè)邊欄分為三個(gè)組,分別為監(jiān)控?cái)?shù)據(jù),事件和報(bào)告。從接到請(qǐng)求到響應(yīng)處理完成的過(guò)程為稱為一次事務(wù)。針對(duì)應(yīng)用,還提供性能監(jiān)控?cái)?shù)據(jù),包括內(nèi)存使用,線程數(shù)等等。
New Relic性能監(jiān)控(二)應(yīng)用監(jiān)控APM
2018-04-12 瑯琊書生本系列文章基于公司使用New Relic的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把我工作中了解到的知識(shí)分享給大家,希望可以給需要的朋友帶來(lái)幫助。
上期文章我們對(duì)New Relic的監(jiān)控產(chǎn)品組成做了整體的介紹,今天我們主要來(lái)介紹下服務(wù)端應(yīng)用監(jiān)控產(chǎn)品New Relic APM。
什么是APMAPM全稱是Application Performance Management,即應(yīng)用程序性能監(jiān)控。APM可以全方位監(jiān)控系統(tǒng)運(yùn)行狀態(tài),能夠讓我們獲取詳細(xì)的數(shù)據(jù),包括系統(tǒng)響應(yīng)時(shí)間,吞吐量,定位緩慢的事務(wù),找到應(yīng)用的瓶頸。
APM原理New Relic APM目前支持以下七種語(yǔ)言: Ruby, Java, Node.js, PHP, .NET, Python, Go,有興趣的朋友可以在官方網(wǎng)站查到如何啟用New Relic APM。這里以java為例。New Relic提供了一個(gè)java agent的jar包。在應(yīng)用程序啟動(dòng)時(shí),指定加載該agent,并做好相應(yīng)的設(shè)置,New Relic就可以監(jiān)控你的java應(yīng)用,并定期將收集到數(shù)據(jù)上報(bào)到New Relic的服務(wù)器。
可以看到,New Relic這種非侵入式的應(yīng)用監(jiān)控非常易于使用。事實(shí)上,除了Go語(yǔ)言之外,其他支持的六種語(yǔ)言都是以這種agent的方式實(shí)現(xiàn)監(jiān)控。Go比較特殊。由于Go是編譯成本地代碼(不同于java的字節(jié)碼之類有中間代碼存在的語(yǔ)言),所以需要使用者使用New Relic提供的Go SDK,在代碼中自行植入監(jiān)控代碼。
APM并不是一個(gè)新鮮的東西,早在很多年前就已經(jīng)存在。那么是什么使得New Relic勝出呢?答案是Saas。近幾年云計(jì)算的發(fā)展迅速,越來(lái)越多的應(yīng)用正在開始以服務(wù)的方式提供。早先的APM使用非常不便,用戶需要本地部署服務(wù)器用以存放數(shù)據(jù),被監(jiān)控的應(yīng)用要保證正確的配置以便能夠?qū)?shù)據(jù)上傳;還需要組建數(shù)據(jù)分析團(tuán)隊(duì),針對(duì)收集到的數(shù)據(jù),結(jié)合應(yīng)用的業(yè)務(wù)場(chǎng)景作出具體的分析工作。這些工作都要耗費(fèi)很多的資源。New Relic把這一切簡(jiǎn)化,以服務(wù)的方式提供APM功能。用戶只需要加載對(duì)應(yīng)語(yǔ)言的agent,就能夠自動(dòng)監(jiān)控應(yīng)用,上報(bào)數(shù)據(jù),分析結(jié)果等。所有的工作都有New Relic提供的工具來(lái)完成。
APM采集的數(shù)據(jù)分析
圖 1: New Relic APM工作模式
圖二為New Relic上某一應(yīng)用的APM主頁(yè)。
圖2: 某一應(yīng)用的APM頁(yè)面
該頁(yè)面分為兩大塊:左邊的菜單欄和右側(cè)的圖表。
左邊側(cè)邊欄分為三個(gè)組,分別為監(jiān)控?cái)?shù)據(jù),事件和報(bào)告。
監(jiān)控?cái)?shù)據(jù)是New Relic收集到的數(shù)據(jù)匯總。New Relic可以檢測(cè)到應(yīng)用與其他服務(wù)之間的關(guān)聯(lián)和依賴關(guān)系,包括數(shù)據(jù)庫(kù)和外部依賴。這里有個(gè)非常重要的概念:事務(wù)(Transaction)。這里的事務(wù)并非是數(shù)據(jù)庫(kù)事務(wù),而是應(yīng)用對(duì)一次請(qǐng)求的處理。從接到請(qǐng)求到響應(yīng)處理完成的過(guò)程為稱為一次事務(wù)。New Relic能夠精確的監(jiān)控到一次事務(wù)中耗費(fèi)在各個(gè)階段的時(shí)間。在圖二中,黃色部分為數(shù)據(jù)庫(kù)處理時(shí)間,淺藍(lán)色為JVM中耗費(fèi)的時(shí)間。通過(guò)這些數(shù)據(jù)我們能清楚的了解不同的事務(wù)在處理過(guò)程中的瓶頸所在。比如有的事務(wù)在數(shù)據(jù)庫(kù)端要耗費(fèi)大量時(shí)間,意味著有可能需要作優(yōu)化查詢。
New Relic還可以列出每個(gè)事務(wù)耗費(fèi)的時(shí)間,圖三為最為耗時(shí)的事務(wù)列表:
圖三:事務(wù)列表
各事務(wù)按所耗費(fèi)的時(shí)間多少排序,讓我們能夠了解最為耗費(fèi)時(shí)間的處理流程,尋找可以優(yōu)化的區(qū)域。每一個(gè)事務(wù)都有非常詳細(xì)的數(shù)據(jù)。圖四為某一事務(wù)的詳細(xì)時(shí)間話費(fèi)統(tǒng)計(jì)。
圖四:精細(xì)的事務(wù)時(shí)間耗費(fèi)統(tǒng)計(jì)
圖中可以看出,該事務(wù)在數(shù)據(jù)庫(kù)查詢操作上耗費(fèi)了大量的時(shí)間(圖中棕色部分)。而下方的表格則給出了具體的數(shù)據(jù),數(shù)據(jù)庫(kù)查詢 Postgres xyf_size_offset select 是耗時(shí)最久的部分,占整個(gè)事務(wù)一半多的時(shí)間。那么整個(gè)應(yīng)用所有的數(shù)據(jù)庫(kù)操作在性能表現(xiàn)上是什么情況呢?圖五就是這方面的統(tǒng)計(jì)。
圖五:數(shù)據(jù)庫(kù)訪問(wèn)性能統(tǒng)計(jì)
我們發(fā)現(xiàn),剛才的那個(gè)數(shù)據(jù)庫(kù)操作不僅是那個(gè)事務(wù)中性能最差的,在所有的數(shù)據(jù)庫(kù)操作中都是耗時(shí)最久的。
針對(duì)java應(yīng)用,APM還提供JVM性能監(jiān)控?cái)?shù)據(jù),包括內(nèi)存使用,線程數(shù)等等。
APM支持告警設(shè)置。用戶可以設(shè)置監(jiān)控指標(biāo)和期望的性能表現(xiàn)。一旦指標(biāo)在一定時(shí)間內(nèi)未能達(dá)到要求,則自動(dòng)發(fā)出告警。告警可以發(fā)送到郵箱或者其他一些即時(shí)通訊工具,使得運(yùn)維人員能及時(shí)獲知系統(tǒng)異常情況。
總結(jié)
圖六:告警
New Relic APM使用方便,數(shù)據(jù)全面,數(shù)據(jù)展示詳細(xì),非常值得一試。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/69120.html
摘要:性能概覽下圖為一個(gè)監(jiān)控的的性能概覽頁(yè)面該頁(yè)面主要包含下面幾個(gè)部分的內(nèi)容頁(yè)面加載時(shí)間曲線得分圖各瀏覽器的吞吐量會(huì)話追蹤,錯(cuò)誤,以及響應(yīng)時(shí)間。吞吐量吞吐量是按瀏覽器的類型繪制的,單位是每分鐘瀏覽量。 New Relic性能監(jiān)控(三)瀏覽器端監(jiān)控 2018-05-02 瑯琊書生本系列文章基于公司使用New Relic的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把我工作中了解到的知識(shí)分享給大家,希...
摘要:性能概覽下圖為一個(gè)監(jiān)控的的性能概覽頁(yè)面該頁(yè)面主要包含下面幾個(gè)部分的內(nèi)容頁(yè)面加載時(shí)間曲線得分圖各瀏覽器的吞吐量會(huì)話追蹤,錯(cuò)誤,以及響應(yīng)時(shí)間。吞吐量吞吐量是按瀏覽器的類型繪制的,單位是每分鐘瀏覽量。 New Relic性能監(jiān)控(三)瀏覽器端監(jiān)控 2018-05-02 瑯琊書生本系列文章基于公司使用New Relic的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把我工作中了解到的知識(shí)分享給大家,希...
摘要:性能概覽下圖為一個(gè)監(jiān)控的的性能概覽頁(yè)面該頁(yè)面主要包含下面幾個(gè)部分的內(nèi)容頁(yè)面加載時(shí)間曲線得分圖各瀏覽器的吞吐量會(huì)話追蹤,錯(cuò)誤,以及響應(yīng)時(shí)間。吞吐量吞吐量是按瀏覽器的類型繪制的,單位是每分鐘瀏覽量。 New Relic性能監(jiān)控(三)瀏覽器端監(jiān)控 2018-05-02 瑯琊書生本系列文章基于公司使用New Relic的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把我工作中了解到的知識(shí)分享給大家,希...
摘要:性能監(jiān)控一概覽瑯琊書生本系列文章基于公司使用的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把我工作中了解到的知識(shí)分享給大家,希望可以給需要的朋友帶來(lái)幫助。提供了端到端的監(jiān)控能力,從前端頁(yè)面性能,到后臺(tái)服務(wù)端的響應(yīng)速度,都有非常詳盡的監(jiān)控?cái)?shù)據(jù)。 New Relic性能監(jiān)控(一)概覽 2018-04-12 瑯琊書生本系列文章基于公司使用New Relic的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把...
摘要:性能監(jiān)控一概覽瑯琊書生本系列文章基于公司使用的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把我工作中了解到的知識(shí)分享給大家,希望可以給需要的朋友帶來(lái)幫助。提供了端到端的監(jiān)控能力,從前端頁(yè)面性能,到后臺(tái)服務(wù)端的響應(yīng)速度,都有非常詳盡的監(jiān)控?cái)?shù)據(jù)。 New Relic性能監(jiān)控(一)概覽 2018-04-12 瑯琊書生本系列文章基于公司使用New Relic的經(jīng)驗(yàn),鑒于國(guó)內(nèi)較少有這方面的文章,因此把...
閱讀 1413·2023-04-26 03:04
閱讀 2365·2019-08-30 15:44
閱讀 3736·2019-08-30 14:15
閱讀 3541·2019-08-27 10:56
閱讀 2759·2019-08-26 13:53
閱讀 2627·2019-08-26 13:26
閱讀 3089·2019-08-26 12:11
閱讀 3618·2019-08-23 18:21