13518219792
APM，全稱：Application Performance Management，目前市面的系統(tǒng)基本都是參考Google的Dapper（大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)）來做的，翻譯傳送門《google的Dapper 中文翻譯》
思考下：不遵守該理論的是偽APM，耍流氓嗎？
APM的核心思想是什么？在應(yīng)用服務(wù)各節(jié)點(diǎn)相互調(diào)用的時(shí)候，從中記錄并傳遞一個(gè)應(yīng)用級別的標(biāo)記，這個(gè)標(biāo)記可以用來關(guān)聯(lián)各個(gè)服務(wù)節(jié)點(diǎn)之間的關(guān)系。比如兩個(gè)應(yīng)用服務(wù)節(jié)點(diǎn)之間使用 HTTP 作為傳輸協(xié)議的話，那么這些標(biāo)記就會(huì)被加入到 HTTP 頭中。可見如何傳遞這些標(biāo)記是與應(yīng)用服務(wù)節(jié)點(diǎn)之間使用的通訊協(xié)議有關(guān)的，常用的協(xié)議就相對容易加入這些內(nèi)容，一些按需定制的可能就相對困難些，這一點(diǎn)也直接決定了實(shí)現(xiàn)分布式追蹤系統(tǒng)的難度。
2、為什么要用APM?有業(yè)務(wù)痛點(diǎn)，才要尋求解決方案，個(gè)人認(rèn)為，APM需要優(yōu)先解決測試環(huán)境下兩個(gè)場景問題，基于測試先行的原則考慮：
優(yōu)先關(guān)注宏觀數(shù)據(jù)，并不是說測試人員無須關(guān)注微觀層面的問題，在測試角度來看，先解決性能測試環(huán)境的數(shù)據(jù)采樣、收集問題，再去評估生產(chǎn)環(huán)境，而線上的鏈路監(jiān)控需要研發(fā)跟運(yùn)維去配合，【研發(fā)角度場景】相對于測試人員來說是弱關(guān)注了。
3、市面上有哪些APM工具？Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java.
https://github.com/naver/pinpoint
A distributed tracing system, and APM ( Application Performance Monitoring ) .
http://skywalking.org
Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.
http://zipkin.io/
CAT基于Java開發(fā)的實(shí)時(shí)應(yīng)用監(jiān)控平臺(tái)，包括實(shí)時(shí)應(yīng)用監(jiān)控，業(yè)務(wù)監(jiān)控。
https://github.com/dianping/cat
目前比較貼合 Google Dapper 原理設(shè)計(jì)的，Pinpoint 優(yōu)于 Zipkin。
Pinpoint對代碼的零侵入，運(yùn)用JavaAgent字節(jié)碼增強(qiáng)技術(shù)，添加啟動(dòng)參數(shù)即可。
并且符合【測試角度場景】性能測試調(diào)優(yōu)監(jiān)控的宏觀；
當(dāng)然，結(jié)論太早了，會(huì)有疑惑：
"Spring Cloud Slueth和zipkin之間的關(guān)系是什么？"
需要看詳細(xì)對比的，詳見下圖：
本質(zhì)上 Spring Cloud Slueth 與 Pinpoint 沒有可比性，真正對比的是Zipkin，Spring Cloud Slueth 聚焦在鏈路追蹤和分析，將信息發(fā)送到Zipkin，利用 Zipkin的存儲(chǔ)來存儲(chǔ)信息，當(dāng)然，Zipkin也可以使用ELK來記錄日志和展示，再通過收集服務(wù)器性能的腳本把數(shù)據(jù)存儲(chǔ)到ELK，則可以展示服務(wù)器狀況信息了。Zipkin的總體展示，也是基于鏈路分析為主。
Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java. 
架構(gòu)圖對應(yīng)說明：
Pinpoint 消息的數(shù)據(jù)結(jié)構(gòu)主要包含三種類型 Span，Trace 和 TraceId。
Span 是最基本的調(diào)用追蹤單元
當(dāng)遠(yuǎn)程調(diào)用到達(dá)的時(shí)候，Span 指代處理該調(diào)用的作業(yè)，并且攜帶追蹤數(shù)據(jù)。為了實(shí)現(xiàn)代碼級別的可見性，Span 下面還包含一層 SpanEvent 的數(shù)據(jù)結(jié)構(gòu)。每個(gè) Span 都包含一個(gè) SpanId。
Trace 是一組相互關(guān)聯(lián)的 Span 集合
同一個(gè) Trace 下的 Span 共享一個(gè) TransactionId，而且會(huì)按照 SpanId 和 ParentSpanId 排列成一棵有層級關(guān)系的樹形結(jié)構(gòu)。
TraceId 是 TransactionId、SpanId 和 ParentSpanId 的組合
TransactionId（TxId）是一個(gè)交易下的橫跨整個(gè)分布式系統(tǒng)收發(fā)消息的 ID，其必須在整個(gè)服務(wù)器組中是全局唯一的。也就是說 TransactionId 識別了整個(gè)調(diào)用鏈；SpanId（SpanId）是處理遠(yuǎn)程調(diào)用作業(yè)的 ID，當(dāng)一個(gè)調(diào)用到達(dá)一個(gè)節(jié)點(diǎn)的時(shí)候隨即產(chǎn)生；ParentSpanId（pSpanId）顧名思義，就是產(chǎn)生當(dāng)前 Span 的調(diào)用方 Span 的 ID。如果一個(gè)節(jié)點(diǎn)是交易的最初發(fā)起方，其 ParentSpanId 是 -1，以標(biāo)志其是整個(gè)交易的根 Span。下圖能夠比較直觀的說明這些 ID 結(jié)構(gòu)之間的關(guān)系。
網(wǎng)上太多部署文檔，這里不詳細(xì)說明，簡要說明下：境要求.png)
注意版本要求：
CATALINA_OPTS="$CATALINA_OPTS -javaagent:/home/webapps/service/pp-agent/pinpoint-bootstrap-1.6.2.jar"
CATALINA_OPTS="$CATALINA_OPTS -Dpinpoint.agentId=pp32tomcattest"
CATALINA_OPTS="$CATALINA_OPTS -Dpinpoint.applicationName=32tomcat"第一行：pinpoint-bootstrap-1.6.2.jar的位置
第二行：agentId必須唯一,標(biāo)志一個(gè)jvm
第三行：applicationName表示同一種應(yīng)用：同一個(gè)應(yīng)用的不同實(shí)例應(yīng)該使用不同的agentId,相同的applicationName
方式二：SpringBoot啟動(dòng)
java -javaagent:/home/webapps/pp-agent/pinpoint-bootstrap-1.6.2.jar -Dpinpoint.agentId=pp32tomcattest -Dpinpoint.applicationName=32tomcat -jar 32tomcat-0.0.1-SNAPSHOT.jar
Pinpoint 對代碼注入的封裝非常類似 AOP，當(dāng)一個(gè)類被加載的時(shí)候會(huì)通過 Interceptor 向指定的方法前后注入 before 和 after 邏輯，在這些邏輯中可以獲取系統(tǒng)運(yùn)行的狀態(tài)，并通過 TraceContext 創(chuàng)建 Trace 消息，并發(fā)送給 Pinpoint 服務(wù)器。但與 AOP 不同的是，Pinpoint 在封裝的時(shí)候考慮到了更多與目標(biāo)代碼的交互能力，因此用 Pinpoint 提供的 API 來編寫代碼會(huì)比 AOP 更加容易和專業(yè)。
搭建一個(gè)java開源項(xiàng)目jforum，跑在tomcat下，使用jmeter進(jìn)行壓測，用戶100個(gè)：
服務(wù)器圖（ServerMap）
通過可視化其組件的互連方式來了解任何分布式系統(tǒng)的拓?fù)洹螕艄?jié)點(diǎn)將顯示有關(guān)組件的詳細(xì)信息，例如其當(dāng)前狀態(tài)和事務(wù)計(jì)數(shù)。
實(shí)時(shí)活動(dòng)線程圖（Realtime Active Thread Chart）
實(shí)時(shí)監(jiān)視應(yīng)用程序內(nèi)的活動(dòng)線程。（用了官方圖，當(dāng)時(shí)沒截圖）
請求/響應(yīng)散布圖（Request/Response Scatter Chart）
可視化請求計(jì)數(shù)和響應(yīng)模式，以確定潛在問題。可以通過在圖表上拖動(dòng)來選擇事務(wù)以獲取更多詳細(xì)信息。散布圖.png)
調(diào)用棧信息（CallStack）
增強(qiáng)分布式環(huán)境中每個(gè)事務(wù)的代碼級可見性，識別單個(gè)視圖中的瓶頸和故障點(diǎn)。用棧信息.png)
查看應(yīng)用程序的其他詳細(xì)信息，如CPU使用率，內(nèi)存/垃圾收集，TPS和JVM參數(shù)。
第一：PinPoint從宏觀上看：總體鏈路、服務(wù)總體狀態(tài)（cpu、內(nèi)存等等信息），符合【測試角度場景】性能測試調(diào)優(yōu)監(jiān)控的宏觀；
第二：Spring Cloud Slueth需要結(jié)合Zipkin從微觀來看：自身無法單獨(dú)提供展示，要結(jié)合Zipkin展示鏈路問題（并沒有服務(wù)器總體狀態(tài)的展示），更多服務(wù)器性能狀況等信息展示需要定制腳本通過ELK收集展示，符合【研發(fā)角度場景】性能測試調(diào)優(yōu)監(jiān)控的微觀；
總的來說兩者是結(jié)合體，要單獨(dú)使用的話，從測試業(yè)務(wù)上來看：PinPoint滿足，性能測試調(diào)優(yōu)監(jiān)控的宏觀【測試角度場景】
7、項(xiàng)目場景訪問某個(gè)API，后端應(yīng)用服務(wù)產(chǎn)生的一系列鏈路，為何請求一次有23次數(shù)據(jù)庫訪問呢？這里就是需要排查的的地方，詳細(xì)看看CallTree，找出可優(yōu)化的SQL查詢語句。
另外，在做性能測試的時(shí)候，服務(wù)器并發(fā)的IO，PP不斷寫入也會(huì)產(chǎn)生瓶頸，需要后續(xù)解決。
通過jmeter對標(biāo)簽庫進(jìn)行簡單壓測，腳本如下：
通過APM發(fā)現(xiàn)問題如下：簽庫-1.png)
pquery.do的res高達(dá)6782ms，需要安排開發(fā)進(jìn)一步排查定位代碼問題簽庫-2.png)
簽庫-3.png)
另外一種場景，測試人員無法在頁面獲取到的信息（有些情況下，測試人員是沒有服務(wù)器權(quán)限），這些是服務(wù)底層的異常信息，可以通過CallTree來查看。
9、應(yīng)用服務(wù)接入APM后的鏈路全景蜘蛛網(wǎng)圖
Pinpoint github
Pinpoint源碼解析（三）
Dapper，大規(guī)模分布式系統(tǒng)的跟蹤系統(tǒng)
Pinpoint學(xué)習(xí)筆記
Pinpoint v1.5.0 APM 視頻介紹
