Pinpoint技術(shù)概述
注： 內(nèi)容翻譯自官方文檔 Technical Overview Of Pinpoint, 內(nèi)容有點長，但是強烈推薦閱讀！基本上這是目前pinpoint唯一的一份詳細(xì)介紹設(shè)計和實現(xiàn)的資料要门。
Pinpoint是一個分析大型分布式系統(tǒng)的平臺匠抗，提供解決方案來處理海量跟蹤數(shù)據(jù)檀葛。2012年七月開始開發(fā)渐溶，2015年1月9日作為開源項目啟動。
本文將介紹Pinpoint： 什么促使我們開始搭建它， 用了什么技術(shù)野芒， 還有Pinpoint agent是如何優(yōu)化的。
開始動機 & Pinpoint特點
和如今相比双炕， 過去的因特網(wǎng)的用戶數(shù)量相對較小狞悲，而因特網(wǎng)服務(wù)的架構(gòu)也沒那么復(fù)雜。web服務(wù)通常使用兩層(web 服務(wù)器和數(shù)據(jù)庫)或三層（web服務(wù)器妇斤，應(yīng)用服務(wù)器和數(shù)據(jù)庫）架構(gòu)摇锋。然而在如今，隨著互聯(lián)網(wǎng)的成長站超，需要支持大量的并發(fā)連接荸恕，并且需要將功能和服務(wù)有機結(jié)合，導(dǎo)致更加復(fù)雜的軟件棧組合死相。更確切地說融求，比三層層次更多的n層架構(gòu)變得更加普遍。SOA或者微服務(wù)架構(gòu)成為現(xiàn)實算撮。
系統(tǒng)的復(fù)雜度因此提升生宛。系統(tǒng)越復(fù)雜，越難解決問題肮柜，例如系統(tǒng)失敗或者性能問題陷舅。在三層架構(gòu)中找到解決方案還不是太難，僅僅需要分析3個組件比如web服務(wù)器审洞，應(yīng)用服務(wù)器和數(shù)據(jù)庫莱睁，而服務(wù)器數(shù)量也不多。但是，如果問題發(fā)生在n層架構(gòu)中仰剿，就需要調(diào)查大量的組件和服務(wù)器耙箍。另一個問題是僅僅分析單個組件很難看到大局;當(dāng)發(fā)生一個低可見度的問題時，系統(tǒng)復(fù)雜度越高酥馍，就需要更長的時間來查找原因。最糟糕的是阅酪，某些情況下我們甚至可能無法查找出來旨袒。
這樣的問題也發(fā)生在NAVER的系統(tǒng)中。使用了大量工具如應(yīng)用性能管理(APM)但是還不足以有效處理問題术辐。因此我們最終決定為n層架構(gòu)開發(fā)新的跟蹤平臺砚尽，為n層架構(gòu)的系統(tǒng)提供解決方案。
Pinpoint, 2012年七月開始開發(fā)辉词，在2015年1月作為一個開源項目啟動, 是一個為大型分布式系統(tǒng)服務(wù)的n層架構(gòu)跟蹤平臺必孤。 Pinpoint的特點如下:
- 分布式事務(wù)跟蹤，跟蹤跨分布式應(yīng)用的消息
- 自動檢測應(yīng)用拓?fù)淙鹛桑瑤椭愀闱宄?yīng)用的架構(gòu)
- 水平擴展以便支持大規(guī)模服務(wù)器集群
- 提供代碼級別的可見性以便輕松定位失敗點和瓶頸
- 使用字節(jié)碼增強技術(shù)敷搪，添加新功能而無需修改代碼
本文將講述Pinpoint的技術(shù)，例如事務(wù)跟蹤和字節(jié)碼增強幢哨。還會解釋應(yīng)用在pinpoint agent中的優(yōu)化方法赡勘，agent修改字節(jié)碼并記錄性能數(shù)據(jù)。
分布式事務(wù)跟蹤捞镰，基于google Dapper
pinpoint跟蹤單個事務(wù)中的分布式請求闸与，基于google Dapper。
在Google Dapper中分布式事務(wù)追蹤是如何工作的
當(dāng)一個消息從Node1發(fā)送到Node2(見圖1)時岸售，分布式追蹤系統(tǒng)的核心是在分布式系統(tǒng)中識別在Node1中處理的消息和在Node2中出的消息之間的關(guān)系践樱。
問題在于無法在消息之間識別關(guān)系。例如凸丸，我們無法識別從Node1發(fā)送的第N個消息和Node2接收到的N'消息之間的關(guān)系拷邢。換句話說，當(dāng)Node1發(fā)送完第X個消息時甲雅，是無法在Node2接收到的N的消息里面識別出第X個消息的解孙。有一種方式試圖在TCP或者操作系統(tǒng)層面追蹤消息。但是抛人，實現(xiàn)很復(fù)雜而且性能低下弛姜，而且需要為每個協(xié)議單獨實現(xiàn)。另外妖枚，很難精確追蹤消息廷臼。
不過，Google dapper實現(xiàn)了一個簡單的解決方案來解決這個問題。這個解決方案通過在發(fā)送消息時添加應(yīng)用級別的標(biāo)簽作為消息之間的關(guān)聯(lián)荠商。例如寂恬，在HTTP請求中的HTTP header中為消息添加一個標(biāo)簽信息并使用這個標(biāo)簽跟蹤消息。
Google's Dapper
關(guān)于Google Dapper的更多信息, 請見 "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure."
Pinpoint基于google dapper的跟蹤技術(shù),但是已經(jīng)修改為在調(diào)用的header中添加應(yīng)用級別標(biāo)簽數(shù)據(jù)以便在遠(yuǎn)程調(diào)用中跟蹤分布式事務(wù)莱没。標(biāo)簽數(shù)據(jù)由多個key組成初肉，定義為TraceId。
Pinpoint中的數(shù)據(jù)結(jié)構(gòu)
Pinpoint中饰躲，核心數(shù)據(jù)結(jié)構(gòu)由Span, Trace, 和 TraceId組成牙咏。
- Span: RPC (遠(yuǎn)程過程調(diào)用/remote procedure call)跟蹤的基本單元; 當(dāng)一個RPC調(diào)用到達(dá)時指示工作已經(jīng)處理完成并包含跟蹤數(shù)據(jù)。為了確保代碼級別的可見性嘹裂，Span擁有帶SpanEvent標(biāo)簽的子結(jié)構(gòu)作為數(shù)據(jù)結(jié)構(gòu)妄壶。每個Span包含一個TraceId。
- Trace: 多個Span的集合; 由關(guān)聯(lián)的RPC (Spans)組成. 在同一個trace中的span共享相同的TransactionId寄狼。Trace通過SpanId和ParentSpanId整理為繼承樹結(jié)構(gòu).
- TraceId: 由 TransactionId, SpanId, 和 ParentSpanId 組成的key的集合. TransactionId 指明消息ID丁寄，而SpanId 和 ParentSpanId 表示RPC的父-子關(guān)系。
- TransactionId (TxId): 在分布式系統(tǒng)間單個事務(wù)發(fā)送/接收的消息的ID; 必須跨整個服務(wù)器集群做到全局唯一.
- SpanId: 當(dāng)收到RPC消息時處理的工作的ID; 在RPC請求到達(dá)節(jié)點時生成泊愧。
- ParentSpanId (pSpanId): 發(fā)起RPC調(diào)用的父span的SpanId. 如果節(jié)點是事務(wù)的起點伊磺，這里將沒有父span - 對于這種情況， 使用值-1來表示這個span是事務(wù)的根span拼卵。
Google Dapper 和 NAVER Pinpoint在術(shù)語上的不同
Pinpoint中的術(shù)語"TransactionId"和google dapper中的術(shù)語"TraceId"有相同的含義奢浑。而Pinpoint中的術(shù)語"TraceId"引用到多個key的集合。
TraceId如何工作
下圖描述TraceId的行為腋腮，在4個節(jié)點之間執(zhí)行了3次的RPC調(diào)用：
在圖2中雀彼，TransactionId (TxId) 體現(xiàn)了三次不同的RPC作為單個事務(wù)被相互關(guān)聯(lián)。但是即寡，TransactionId 本身不能精確描述PRC之間的關(guān)系徊哑。為了識別PRC之間的關(guān)系，需要SpanId 和 ParentSpanId (pSpanId). 假設(shè)一個節(jié)點是Tomcat聪富，可以將SpanId想象為處理HTTP請求的線程莺丑，ParentSpanId代表發(fā)起這個RPC調(diào)用的SpanId.
使用TransactionId，Pinpoint可以發(fā)現(xiàn)關(guān)聯(lián)的n個Span墩蔓，并使用SpanId和ParentSpanId將這n個span排列為繼承樹結(jié)構(gòu)梢莽。
SpanId 和 ParentSpanId 是 64位長度的整型〖榕可能發(fā)生沖突昏名，因為這個數(shù)字是任意生成的，但是考慮到值的范圍可以從-9223372036854775808到9223372036854775807阵面，不太可能發(fā)生沖突. 如果key之間出現(xiàn)沖突轻局，Pinpoint和Google Dapper系統(tǒng)洪鸭，會讓開發(fā)人員知道發(fā)生了什么，而不是解決沖突仑扑。
TransactionId 由 AgentIds, JVM (java虛擬機)啟動時間, 和 SequenceNumbers/序列號組成.
- AgentId: 當(dāng)Jvm啟動時用戶創(chuàng)建的ID; 必須在pinpoinit安裝的全部服務(wù)器集群中全局唯一. 最簡單的讓它保持唯一的方法是使用hostname($HOSTNAME)览爵，因為hostname一般不會重復(fù). 如果需要在服務(wù)器集群中運行多個JVM，請在hostname前面增加一個前綴來避免重復(fù)镇饮。
- JVM 啟動時間: 需要用來保證從0開始的SequenceNumber的唯一性. 當(dāng)用戶錯誤的創(chuàng)建了重復(fù)的AgentId時這個值可以用來預(yù)防ID沖突蜓竹。
- SequenceNumber: Pinpoint agent 生成的ID, 從0開始連續(xù)自增;為每個消息生成一個.
Dapper 和 Zipkin, Twitter的一個分布式系統(tǒng)跟蹤平臺, 生成隨機TraceIds (Pinpoint是TransactionIds) 并將沖突情況視為正常。然而, 在Pinpiont中我們想避免沖突的可能储藐，因此實現(xiàn)了上面描述的系統(tǒng)梅肤。有兩種選擇：一是數(shù)據(jù)量小但是沖突的可能性高，二是數(shù)據(jù)量大但是沖突的可能性低邑茄。我們選擇了第二種。
可能有更好的方式來處理transaction俊啼。我們起先有一個想法肺缕，通過中央key服務(wù)器來生成key。如果實現(xiàn)這個模式授帕，可能導(dǎo)致性能問題和網(wǎng)絡(luò)錯誤同木。因此，大量生成key被考慮作為備選跛十。后面這個方法可能被開發(fā)⊥罚現(xiàn)在采用簡單方法。在pinpoint中芥映，TransactionId被當(dāng)成可變數(shù)據(jù)來對待洲尊。
字節(jié)碼增強，無需代碼修改
前面我們解釋了分布式事務(wù)跟蹤奈偏。實現(xiàn)的方法之一是開發(fā)人員自己修改代碼坞嘀。當(dāng)發(fā)生RPC調(diào)用時容許開發(fā)人員添加標(biāo)簽信息。但是惊来，修改代碼會成為包袱丽涩，即使這樣的功能對開發(fā)人員非常有用。
Twitter的 Zipkin 使用修改過的類庫和它自己的容器(Finagle)來提供分布式事務(wù)跟蹤的功能裁蚁。但是矢渊，它要求在需要時修改代碼。我們期望功能可以不修改代碼就工作并希望得到代碼級別的可見性枉证。為了解決這個問題矮男，pinpoint中使用了字節(jié)碼增強技術(shù)。Pinpoint agent干預(yù)發(fā)起RPC的代碼以此來自動處理標(biāo)簽信息刽严。
克服字節(jié)碼增強的缺點
字節(jié)碼增強在手工方法和自動方法兩者之間屬于自動方法昂灵。
- 手工方法： 開發(fā)人員使用ponpoint提供的API在關(guān)鍵點開發(fā)記錄數(shù)據(jù)的代碼
- 自動方法： 開發(fā)人員不需要代碼改動避凝，因為pinpoint決定了哪些API要調(diào)節(jié)和開發(fā)
下面是每個方法的優(yōu)點和缺點：
Table1 每個方法的優(yōu)缺點
| 優(yōu)點 | 缺點 | |
|---|---|---|
| 手工跟蹤 | 1. 要求更少開發(fā)資源 2. API可以更簡單并最終減少bug的數(shù)量 | 1. 開發(fā)人員必須修改代碼 2. 跟蹤級別低 |
| 自動跟蹤 | 1. 開發(fā)人員不需要修改代碼 2. 可以收集到更多精確的數(shù)據(jù)因為有字節(jié)碼中的更多信息 | 1. 在開發(fā)pinpoint時，和實現(xiàn)一個手工方法相比眨补，需要10倍開銷來實現(xiàn)一個自動方法 2. 需要更高能力的開發(fā)人員管削，可以立即識別需要跟蹤的類庫代碼并決定跟蹤點 3. 增加bug發(fā)生的可能性，因為使用了如字節(jié)碼增強這樣的高級開發(fā)技巧 |
字節(jié)碼增強是一種高難度和高風(fēng)險的技術(shù)撑螺。但是含思，綜合考慮使用這種技術(shù)開所需要的資源和難度，使用它仍然有很多的益處甘晤。
雖然它需要大量的開發(fā)資源含潘，在開發(fā)服務(wù)上它需要很少的資源。例如线婚，下面展示了使用字節(jié)碼增強的自動方法和使用類庫的手工方法(在這里的上下文中遏弱，開銷是為澄清而假設(shè)的隨機數(shù))之間的開銷。
-
自動方法: 總共 100
- Pinpoint開發(fā)開銷: 100
- 服務(wù)實施的開銷: 0
-
手工方法: 總共 30
- Pinpoint開發(fā)開銷: 20
- 服務(wù)實施的開銷: 10
上面的數(shù)據(jù)告訴我們手工方法比自動方法有更合算塞弊。但是漱逸，不適用于我們的在NAVER的環(huán)境。在NAVER我們有幾千個服務(wù)游沿，因此在上面的數(shù)據(jù)中需要修改用于服務(wù)實施的開銷饰抒。如果我們有10個服務(wù)需要修改，總開銷計算如下：
Pinpoint開發(fā)開銷 20 + 服務(wù)實施開銷 10 x 10 = 120
基于這個結(jié)果诀黍，自動方法是一個更合算的方式袋坑。
我們很幸運的在pinpoint團隊中擁有很多高能力而專注于Java的開發(fā)人員。因此眯勾，我們相信克服pinpoint開發(fā)中的技術(shù)難題只是個時間問題枣宫。
字節(jié)碼增強的價值
我們選擇字節(jié)碼增強的理由，除了前面描述的那些外吃环，還有下面的強有力的觀點：
隱藏API
一旦API被暴露給開發(fā)人員使用镶柱，我們作為API的提供者，就不能隨意的修改API模叙。這樣的限制會給我們增加壓力歇拆。
我們可能修改API來糾正錯誤設(shè)計或者添加新的功能。但是范咨，如果做這些受到限制故觅，對我們來說很難改進(jìn)API。解決這個問題的最好的答案是一個可升級的系統(tǒng)設(shè)計渠啊，而每個人都知道這不是一個容易的選擇输吏。如果我們不能掌控未來，就不可能創(chuàng)建完美的API設(shè)計替蛉。
而使用字節(jié)碼增強技術(shù)贯溅，我們就不必?fù)?dān)心暴露跟蹤API而可以持續(xù)改進(jìn)設(shè)計拄氯，不用考慮依賴關(guān)系。對于那些計劃使用pinpoint開發(fā)應(yīng)用的人它浅，換一句話說译柏，這代表對于pinpoint開發(fā)人員，API是可變的〗慊簦現(xiàn)在鄙麦，我們將保留隱藏API的想法，因為改進(jìn)性能和設(shè)計是我們的第一優(yōu)先級镊折。
容易啟用或者禁用
使用字節(jié)碼增強的缺點是當(dāng)Pinpoint自身類庫的采樣代碼出現(xiàn)問題時可能影響應(yīng)用胯府。不過，可以通過啟用或者禁用pinpoint來解決問題恨胚，很簡單骂因，因為不需要修改代碼。
通過增加下面三行到JVM啟動腳本中就可以輕易的為應(yīng)用啟用pinpoint：
-javaagent:$AGENT_PATH/pinpoint-bootstrap-$VERSION.jar
-Dpinpoint.agentId=<Agent's UniqueId>
-Dpinpoint.applicationName=<The name indicating a same service (AgentId collection)>
如果因為pinpoint發(fā)生問題赃泡，只需要在JVM啟動腳本中刪除這些配置數(shù)據(jù)侣签。
字節(jié)碼如何工作
由于字節(jié)碼增強技術(shù)處理java字節(jié)碼， 有增加開發(fā)風(fēng)險的趨勢急迂，同時會降低效率。另外蹦肴，開發(fā)人員更容易犯錯僚碎。在pinpoint，我們通過抽象出攔截器(interceptor)來改進(jìn)效率和可達(dá)性(accessibility)阴幌。pinpoint在類裝載時通過介入應(yīng)用代碼為分布式事務(wù)和性能信息注入必要的跟蹤代碼勺阐。這會提升性能，因為代碼注入是在應(yīng)用代碼中直接實施的矛双。
在pinpoint中渊抽，攔截器API在性能數(shù)據(jù)被記錄的地方分開(separated)。為了跟蹤议忽，我們添加攔截器到目標(biāo)方法使得before()方法和after()方法被調(diào)用懒闷，并在before()方法和after()方法中實現(xiàn)了部分性能數(shù)據(jù)的記錄。使用字節(jié)碼增強栈幸，pinpoint agent可以記錄需要方法的數(shù)據(jù)愤估，只有這樣采樣數(shù)據(jù)的大小才能變小。
pinpoint agent的性能優(yōu)化
最后速址，我們描述用于pinpoint agent的性能優(yōu)化的方式玩焰。
使用二進(jìn)制格式(thrift)
通過使用二進(jìn)制格式(thrift)可以提高編碼速度，雖然它使用和調(diào)試要難一些芍锚。也有利于減少網(wǎng)絡(luò)使用昔园，因為生成的數(shù)據(jù)比較小蔓榄。
使用變長編碼和格式優(yōu)化數(shù)據(jù)記錄
如果將一個長整型轉(zhuǎn)換為固定長度的字符串， 數(shù)據(jù)大小一般是8個字節(jié)默刚。然而甥郑，如果你用變長編碼，數(shù)據(jù)大小可以是從1到10個字符羡棵，取決于給定數(shù)字的大小壹若。為了減小數(shù)據(jù)大小，pinpoint使用thrift的CompactProtocol協(xié)議（壓縮協(xié)議)來編碼數(shù)據(jù)皂冰，因為變長字符串和記錄數(shù)據(jù)可以為編碼格式做優(yōu)化店展。pinpoint agent通過基于跟蹤的根方法的時間開始來轉(zhuǎn)換其他的時間來減少數(shù)據(jù)大小。
圖4 說明了上面章節(jié)描述的想法：
為了得到關(guān)于三個不同方法（見圖4）被調(diào)用時間的數(shù)據(jù)秃流，不得不在6個不同的點上測量時間赂蕴，用固定長度編碼這需要48個字節(jié)(6 * 8)。
以此同時舶胀，pinpoint agent 使用可變長度編碼并根據(jù)對應(yīng)的格式記錄數(shù)據(jù)概说。然后在其他時間點通過和參考點比較來計算時間值（在vector中），根方法的起點被確認(rèn)為參考點嚣伐。這只需要占用少量的字節(jié)糖赔，因為vector使用小數(shù)字。圖4中消耗了13個字節(jié)轩端。
如果執(zhí)行方法花費了更多時間放典，即使使用可變長度編碼也會增加字節(jié)數(shù)量。但是基茵，依然比固定長度編碼更有效率奋构。
用常量表替換重復(fù)的API信息，SQL語句和字符串
我們希望pinpoint能開啟代碼級別的跟蹤拱层。然而弥臼，存在增大數(shù)據(jù)大小的問題。每次高精度的數(shù)據(jù)被發(fā)送到服務(wù)器將增大數(shù)據(jù)大小根灯，導(dǎo)致增加網(wǎng)絡(luò)使用径缅。
為了解決這個問題，我們使用了在遠(yuǎn)程HBase中創(chuàng)建常量表的策略烙肺。例如芥驳，每次調(diào)用"Method A"的信息被發(fā)送到pinpoint collector， 數(shù)據(jù)大小將很大茬高。pinpoint agent 用一個ID替換"method A"兆旬，在HBase中作為一個常量表保存ID和"method A"的信息，然后用ID生成跟蹤數(shù)據(jù)怎栽。然后當(dāng)用戶在網(wǎng)站上獲取跟蹤數(shù)據(jù)時丽猬，pinpoint web在常量表中搜索對應(yīng)ID的方法信息并組合他們宿饱。使用同樣的方式來減少SQL或者頻繁使用的字符串的數(shù)據(jù)大小。
處理大量請求的采樣
我們在線門戶服務(wù)有海量請求脚祟。單個服務(wù)每天處理超過200億請求谬以。容易跟蹤這樣的請求：方法是添加足夠多的網(wǎng)絡(luò)設(shè)施和服務(wù)器來跟蹤請求并擴展服務(wù)器來收集數(shù)據(jù)。然后由桌，這不是處理這種場景的合算的方法为黎，僅僅是浪費金錢和資源。
在Pinpoint行您，可以收集采樣資料而不必跟蹤每個請求铭乾。在開發(fā)環(huán)境中請求量很小，每個數(shù)據(jù)都收集娃循。而在產(chǎn)品環(huán)境請求量巨大炕檩，收集小比率的數(shù)據(jù)如1~5%，足夠檢查整個應(yīng)用的狀態(tài)捌斧。有采樣后笛质，可以最小化應(yīng)用的網(wǎng)絡(luò)開銷并降低諸如網(wǎng)絡(luò)和服務(wù)器的設(shè)施費用。
pinpoint采樣方法
Pinpoint 支持計數(shù)采樣捞蚂，如果設(shè)置為10則只采樣10分之一的請求妇押。我們計劃增加新的采樣器來更有效率的收集數(shù)據(jù)。
注：對應(yīng)的配置項在agent下的pinpoint.config文件中姓迅，默認(rèn)"profiler.sampling.rate=1"表示全部
使用異步數(shù)據(jù)傳輸來最小化應(yīng)用線程中止
pinpoint不阻塞應(yīng)用線程敲霍，因為編碼后的數(shù)據(jù)或者遠(yuǎn)程消息被其他線程異步傳輸。
使用UDP傳輸數(shù)據(jù)
和gogole dapper不同队贱，pinpoint通過網(wǎng)絡(luò)傳輸數(shù)據(jù)來確保數(shù)據(jù)速度。作為一個服務(wù)間使用的通用設(shè)施潭袱，當(dāng)數(shù)據(jù)通訊持續(xù)突發(fā)時網(wǎng)絡(luò)會成為問題柱嫌。在這種情況下，pinpoint agent使用UDP協(xié)議來給服務(wù)讓出網(wǎng)絡(luò)連接優(yōu)先級屯换。
注意
數(shù)據(jù)傳輸API可以被替換编丘，因為它是接口分離的⊥冢可以修改實現(xiàn)為用其他方式存儲數(shù)據(jù)嘉抓，比如本地文件。
pinpoint應(yīng)用示例
這里給出一個例子關(guān)于如何從應(yīng)用獲取數(shù)據(jù)晕窑，這樣就可以全面的理解前面講述的內(nèi)容抑片。
圖5 展示了當(dāng)在 TomcatA 和 TomcatB 中安裝pinpoint的數(shù)據(jù)⊙畛啵可以把單個節(jié)點的跟蹤數(shù)據(jù)看成single traction敞斋，提現(xiàn)分布式事務(wù)跟蹤的流程截汪。
下面闡述pinpoint為每個方法做了什么：
-
當(dāng)請求到達(dá)TomcatA時, Pinpoint agent 產(chǎn)生一個 TraceId.
- TX_ID: TomcatA^TIME^1
- SpanId: 10
- ParentSpanId: -1(Root)
從spring MVC 控制器中記錄數(shù)據(jù)
-
插入HttpClient.execute()方法的調(diào)用并在HTTPGet中配置TraceId
-
創(chuàng)建一個子TraceId
- TX_ID: TomcatA^TIME^1 -> TomcatA^TIME^1
- SPAN_ID: 10 -> 20
- PARENT_SPAN_ID: -1 -> 10 (父 SpanId)
-
在HTTP header中配置子 TraceId
- HttpGet.setHeader(PINPOINT_TX_ID, "TomcatA^TIME^1")
- HttpGet.setHeader(PINPOINT_SPAN_ID, "20")
- HttpGet.setHeader(PINPOINT_PARENT_SPAN_ID, "10")
-
-
傳輸打好tag的請求到TomcatB.
-
TomcatB 檢查傳輸過來的請求的header
HttpServletRequest.getHeader(PINPOINT_TX_ID)
-
TomcatB 作為子節(jié)點工作因為它識別了header中的TraceId
- TX_ID: TomcatA^TIME^1
- SPAN_ID: 20
- PARENT_SPAN_ID: 10
-
從spring mvc控制器中記錄數(shù)據(jù)并完成請求
- 當(dāng)從tomcatB回來的請求完成時，pinpoint agent發(fā)送跟蹤數(shù)據(jù)到pinpoint collector就此存儲在HBase中
- 在對tomcatB的HTTP調(diào)用結(jié)束后植捎，TomcatA的請求也完成了衙解。pinpoint agent發(fā)送跟蹤數(shù)據(jù)到pinpoint collector就此存儲在HBase中
- UI從HBase中讀取跟蹤數(shù)據(jù)并通過排序樹來創(chuàng)建調(diào)用棧
結(jié)論
pinpoint是和應(yīng)用一起運行的另外的應(yīng)用。使用字節(jié)碼增強使得pinpoint看上去不需要代碼修改焰枢。通常蚓峦，字節(jié)碼增強技術(shù)讓應(yīng)用容易造成風(fēng)險。如果問題發(fā)生在pinpoint中济锄，它會影響應(yīng)用暑椰。目前，我們專注于改進(jìn)pinpoint的性能和設(shè)計拟淮，而不是移除這樣的威脅干茉，因為我們?nèi)蝿?wù)這些讓pinpoint更加有價值。因此你需要決定是否使用pinpoint很泊。
我們還是有大量的工作需要完成來改進(jìn)pinpoint角虫，盡管不完整，pinpoint還是作為開源項目發(fā)布了委造。我們將持續(xù)努力開發(fā)并改進(jìn)pinpoint以便滿足你的期望戳鹅。
Woonduk Kang編寫
在2011年, 關(guān)于我自己我這樣寫到 — 作為一個開發(fā)人員，我想開發(fā)人們愿意付款的軟件程序昏兆，像Microsoft 或者 Oracle. 當(dāng)Pinpoint被作為一個開源項目啟動枫虏，看上去我的夢想稍微實現(xiàn)了一點。目前爬虱， 我的愿望是讓pinpoint對用戶更加有價值和更惹人喜歡.
