本文將講述Pinpoint的技術(shù)朱浴，如事務(wù)追蹤和字節(jié)碼增強(qiáng)鸽素。并介紹應(yīng)用于Pinpoint Agent的優(yōu)化方法肪笋，該方法修改字節(jié)碼并記錄性能數(shù)據(jù)牡辽。
仿照Google Dapper的分布式事務(wù)追蹤
Pinpoint仿照Google Dapper追蹤單個(gè)事務(wù)中的分布式請(qǐng)求粒氧。
在Google Dapper中分布式事務(wù)追蹤如何工作
當(dāng)一個(gè)消息從Node1發(fā)送到Node2時(shí)越除，分布式追蹤系統(tǒng)的作用是：在分布式系統(tǒng)中識(shí)別Node1和Node2之間的關(guān)系。(圖1)
問題是無法識(shí)別消息之間的關(guān)系。例如摘盆，我們無法識(shí)別從Node1發(fā)送的N個(gè)消息與Node2接收到的N'個(gè)消息之間的關(guān)系翼雀。換句話說，當(dāng)?shù)赬個(gè)消息從節(jié)點(diǎn)1被發(fā)送時(shí)孩擂，這個(gè)消息不能在Node2接收到的N'個(gè)消息中被識(shí)別狼渊。
曾經(jīng)試圖在TCP或操作系統(tǒng)級(jí)別跟蹤消息。然而类垦，這樣做實(shí)現(xiàn)復(fù)雜度高且性能低狈邑，因?yàn)樗枰槍?duì)每個(gè)協(xié)議單獨(dú)實(shí)現(xiàn)。除此之外蚤认，這樣做很難準(zhǔn)確地追蹤消息米苹。
然而，Google Dapper實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的解決方案來解決這個(gè)問題砰琢。這個(gè)解決方案是：在發(fā)送一個(gè)消息時(shí)驱入，添加應(yīng)用程序級(jí)的標(biāo)記，這些標(biāo)記可以是消息之間的鏈接氯析。例如亏较，在HTTP請(qǐng)求中的HTTP Header中為一個(gè)消息添加標(biāo)記信息，并使用這個(gè)標(biāo)記追蹤這個(gè)消息掩缓。
Pinpoint基于Google Dapper的追蹤技術(shù)雪情，但是已經(jīng)修改為：在一次遠(yuǎn)程調(diào)用中追蹤分布式事務(wù)，通過在調(diào)用的Header中添加應(yīng)用程序級(jí)的標(biāo)記數(shù)據(jù)你辣。標(biāo)記數(shù)據(jù)由一組Key組成巡通，這些Key被定義為一個(gè)TraceId。
關(guān)于Google Dapper的更多信息舍哄，請(qǐng)看："Dapper, a Large-Scale Distributed Systems Tracing Infrastructure"宴凉。
Pinpoint中的數(shù)據(jù)結(jié)構(gòu)
在Pinpoint中，核心數(shù)據(jù)結(jié)構(gòu)由Spans表悬、Traces和TraceIds組成弥锄。
1.Span：RPC追蹤的基本單元。當(dāng)一個(gè)RPC到達(dá)時(shí)蟆沫，Span標(biāo)示工作已經(jīng)處理完成并包含追蹤數(shù)據(jù)籽暇。為了確保代碼級(jí)別的可見性，一個(gè)Span具有將SpanEvent標(biāo)記為一個(gè)數(shù)據(jù)結(jié)構(gòu)的子節(jié)點(diǎn)饭庞。
2.Trace：一個(gè)Span的集合戒悠。它由有關(guān)聯(lián)的RPCs(Spans)組成。在相同Trace中的Spans舟山，共享相同的TransactionId绸狐。
3.TraceId：由TransactionId卤恳、SpanId和ParentSpanId組成的一個(gè)keys的集合。TransactionId指示消息的ID寒矿，而SpanId和ParentSpanId表示RPCs的父-子關(guān)系纬黎。
4.TransactionId(TxId)：從單個(gè)事務(wù)跨分布式系統(tǒng)發(fā)送/接收的消息的ID。它必須跨整個(gè)服務(wù)器集群做到全局唯一劫窒。
5.SpanId：當(dāng)收到RPC消息時(shí)一個(gè)工作被處理的ID本今。當(dāng)一個(gè)RPC到達(dá)一個(gè)節(jié)點(diǎn)時(shí)生成SpanId。
6.ParentSpanId(pSpanId)：發(fā)起RPC的父Span的SpanId主巍。如果一個(gè)節(jié)點(diǎn)是一個(gè)事務(wù)的起點(diǎn)冠息，將沒有父span - 對(duì)于這種情況，使用值-1表示這個(gè)span是一個(gè)事務(wù)的根span孕索。
Google Dapper和NAVER Pinpoint在術(shù)語(yǔ)上的不同
Pinpoint中的術(shù)語(yǔ)"TransactionId"和Google Dapper中的術(shù)語(yǔ)"TraceId"有相同的含義逛艰。Pinpoint中的術(shù)語(yǔ)“TraceId”指的是一個(gè)keys的集合。
TraceId如何工作
下圖說明了一個(gè)TraceId在4個(gè)節(jié)點(diǎn)之間執(zhí)行了3次RPC調(diào)用時(shí)的運(yùn)轉(zhuǎn)狀態(tài)搞旭。
在圖2中散怖，一個(gè)TransactionId(TxId)表示三個(gè)不同的RPC作為單個(gè)事務(wù)彼此關(guān)聯(lián)。然而肄渗，一個(gè)TransactionId本身不能精確描述PRC調(diào)用之間的關(guān)系镇眷。為了識(shí)別PRC調(diào)用之間的關(guān)系，需要SpanId和ParentSpanId(pSpanId)翎嫡。假設(shè)一個(gè)節(jié)點(diǎn)是Tomcat欠动，可以將一個(gè)SpanId想象成一個(gè)處理HTTP請(qǐng)求的線程。一個(gè)ParentSpanId指示發(fā)起這個(gè)RPC調(diào)用的父SpanId惑申。
使用TransactionId具伍，Pinpoint可以發(fā)現(xiàn)有關(guān)聯(lián)的n個(gè)Span，并能夠使用SpanId和ParentSpanId將這n個(gè)span排列為繼承樹結(jié)構(gòu)圈驼。
一個(gè)SpanId和一個(gè)ParentSpanId是64位長(zhǎng)度的整型人芽。可能產(chǎn)生沖突绩脆，因?yàn)檫@個(gè)數(shù)字是任意生成的萤厅。但是考慮到值的范圍可以從-9223372036854775808到9223372036854775807，因此不太可能會(huì)發(fā)生沖突衙伶。如果Key之間出現(xiàn)沖突祈坠，Pinpoint和Google Dapper會(huì)讓開發(fā)人員知道發(fā)生了什么，而不是解決沖突矢劲。
一個(gè)TransactionId由AgentIds，JVM啟動(dòng)時(shí)間和SequenceNumbers組成慌随。
1.AgentId：當(dāng)JVM啟動(dòng)時(shí)用戶創(chuàng)建的ID芬沉。AgentId必須在安裝了Pinpoinit的全部服務(wù)器集群中全局唯一躺同。最簡(jiǎn)單的讓它保持唯一的方法是使用hostname($HOSTNAME)，因?yàn)閔ostname一般不會(huì)重復(fù)丸逸。如果需要在服務(wù)器集群中運(yùn)行多個(gè)JVM蹋艺，請(qǐng)?jiān)趆ostname后面增加一個(gè)后綴來避免重復(fù)。
2.JVM 啟動(dòng)時(shí)間：需要用來保證從0開始的SequenceNumber的唯一性黄刚。當(dāng)用戶錯(cuò)誤地創(chuàng)建了重復(fù)的AgentId時(shí)捎谨，這個(gè)值可以用來預(yù)防ID沖突。
3.SequenceNumber： Pinpoint Agent生成的ID憔维，從0開始連續(xù)自增涛救，為每個(gè)消息生成一個(gè)。
Dapper和Zipkin(Twitter的一個(gè)分布式系統(tǒng)追蹤平臺(tái))业扒，生成隨機(jī)TraceIds(Pinpoint中的TransactionIds)并將沖突情況視為正常检吆。然而，在Pinpiont中我們想避免沖突的可能程储。有兩種可用的方案：
第一種方法數(shù)據(jù)量小但是沖突的可能性高蹭沛。第二種方法數(shù)據(jù)量大但是沖突的可能性低。我們選擇了第二種章鲤。
可能有更好的方式來處理事務(wù)摊灭。我們提出了幾個(gè)想法，例如通過中央key服務(wù)器發(fā)布key败徊。但是斟或，由于性能問題和網(wǎng)絡(luò)錯(cuò)誤，我們?cè)谙到y(tǒng)中沒有實(shí)現(xiàn)這一點(diǎn)集嵌。我們?nèi)匀话雅堪l(fā)布key作為一個(gè)替代解決方案萝挤。因此未來這個(gè)方法有可能被開發(fā)。但是現(xiàn)在根欧，我們采用了一個(gè)簡(jiǎn)單的方法怜珍。在Pinpoint中，TransactionId被視為可變數(shù)據(jù)凤粗。
字節(jié)碼增強(qiáng)酥泛，無需代碼修改
前面我們解釋了分布式事務(wù)追蹤。實(shí)現(xiàn)的方法之一是開發(fā)人員自己修改代碼嫌拣。當(dāng)發(fā)生RPC調(diào)用時(shí)柔袁，允許開發(fā)人員添加標(biāo)記信息。但是异逐，修改代碼會(huì)成為包袱捶索，即使這樣的功能對(duì)開發(fā)人員非常有用。Twitter的Zipkin使用修改類庫(kù)和它的容器(Finagle)的方式來提供分布式事務(wù)追蹤的功能灰瞻。但是腥例，它要求在需要時(shí)修改代碼辅甥。我們想要這個(gè)功能不修改代碼就可以工作，并且希望確保代碼級(jí)別的可見性燎竖。為了解決這個(gè)問題璃弄，Pinpoint中采用了字節(jié)碼增強(qiáng)技術(shù)。Pinpoint Agent干預(yù)發(fā)起RPC調(diào)用的代碼构回，以此來自動(dòng)處理標(biāo)記信息夏块。
克服字節(jié)碼增強(qiáng)的缺點(diǎn)
如下所示，實(shí)現(xiàn)分布式事務(wù)追蹤有兩種方法纤掸。字節(jié)碼增強(qiáng)是一種自動(dòng)化方法
1.手動(dòng)方法： 開發(fā)人員開發(fā)代碼時(shí)脐供，在關(guān)鍵點(diǎn)使用Pinpoint提供的API記錄數(shù)據(jù)。
2.自動(dòng)方法： 開發(fā)人員不涉及代碼修改茁肠，開發(fā)人員不涉及代碼修改患民，因?yàn)镻inpoint決定要干預(yù)和開發(fā)哪個(gè)API。
下面是每種方法的優(yōu)點(diǎn)和缺點(diǎn)：
字節(jié)碼增強(qiáng)是一種高難度和高風(fēng)險(xiǎn)的技術(shù)垦梆。然而匹颤，使用這種技術(shù)有很多好處。雖然它需要大量的開發(fā)資源托猩，但是應(yīng)用到服務(wù)幾乎不需要任何資源印蓖。例如，下面展示了使用字節(jié)碼增強(qiáng)的自動(dòng)方法和使用類庫(kù)的手動(dòng)方法的成本對(duì)比(在這里的上下文中京腥，成本是為了澄清而假設(shè)的隨機(jī)數(shù))赦肃。
1.自動(dòng)方法：總成本100
①Pinpoint開發(fā)成本：100
②服務(wù)應(yīng)用成本：0
2.手動(dòng)方法：總成本30
①Pinpoint開發(fā)成本：20
②服務(wù)應(yīng)用成本：10
上面的數(shù)據(jù)告訴我們手動(dòng)方法比自動(dòng)方法有更劃算。但是公浪，由于NAVER擁有上千個(gè)服務(wù)他宛，因此無法保證在NAVER有相同的結(jié)果。例如欠气，如果我們有10個(gè)需要修改的服務(wù)厅各，總成本將計(jì)算如下：
Pinpoint開發(fā)成本20+服務(wù)應(yīng)用成本10×10個(gè)服務(wù)=120
正如你所看到的，自動(dòng)方法對(duì)我們來說更加節(jié)省成本预柒。
我們很幸運(yùn)队塘，在Pinpoint團(tuán)隊(duì)中擁有很多高能力并且專注于Java的開發(fā)人員。因此宜鸯，我們相信克服Pinpoint開發(fā)中的技術(shù)難點(diǎn)只是個(gè)時(shí)間問題憔古。
字節(jié)碼增強(qiáng)的價(jià)值
我們選擇字節(jié)碼增強(qiáng)(自動(dòng)方法)的原因，除了前面描述的那些外淋袖，還有下面的要點(diǎn)：
1鸿市、隱藏API
如果API被暴露給開發(fā)人員使用。我們作為API的提供者适贸，根據(jù)需要修改API的行為就會(huì)被限制灸芳。這樣的限制會(huì)給我們帶來壓力涝桅。
我們可能修改API來糾正錯(cuò)誤設(shè)計(jì)或者添加新的功能拜姿。但是烙样，如果做這些受到限制，對(duì)我們來說很難改進(jìn)API蕊肥。解決這個(gè)問題的最好的答案是有一個(gè)可升級(jí)的系統(tǒng)設(shè)計(jì)谒获，而每個(gè)人都知道這不是一個(gè)容易的選擇。創(chuàng)建完美的API設(shè)計(jì)幾乎是不可能的壁却，因?yàn)槲覀儫o法預(yù)測(cè)未來批狱。
使用字節(jié)碼增強(qiáng)，我們不必?fù)?dān)心由于暴露追蹤API而引起的問題展东，并且能夠在不考慮依賴關(guān)系的情況下持續(xù)改進(jìn)設(shè)計(jì)赔硫。對(duì)于那些計(jì)劃使用Pinpoint開發(fā)應(yīng)用程序的人來說，請(qǐng)注意盐肃，Pinpoint開發(fā)人員可以更改API爪膊，因?yàn)楦纳菩阅芎驮O(shè)計(jì)是我們的首要目標(biāo)。
2.容易啟用或禁用
使用字節(jié)碼增強(qiáng)的缺點(diǎn)是砸王，當(dāng)類庫(kù)的分析部分或Pinpoint本身出現(xiàn)問題時(shí)推盛，它可能會(huì)影響你的應(yīng)用程序。但是谦铃，你可以簡(jiǎn)單地通過禁用Pinpoint來解決這個(gè)問題耘成，而不必更改任何代碼。
通過將下面三行（與Pinpoint Agent的配置相關(guān)聯(lián)）添加到JVM啟動(dòng)腳本中驹闰，可以容易地為應(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而出現(xiàn)任何問題瘪菌，你只需要JVM啟動(dòng)腳本中刪除這些配置數(shù)據(jù)。
字節(jié)碼增強(qiáng)如何工作
由于字節(jié)碼增強(qiáng)技術(shù)必須處理Java字節(jié)碼嘹朗，有增加開發(fā)風(fēng)險(xiǎn)的趨勢(shì)师妙，同時(shí)會(huì)降低生產(chǎn)率。此外骡显，開發(fā)人員容易出錯(cuò)疆栏。在Pinpoint中，我們通過攔截器的抽象提高了生產(chǎn)力和可訪問性惫谤。Pinpoint通過在類加載時(shí)壁顶，干預(yù)應(yīng)用程序代碼并注入必要的代碼，來追蹤分布式事務(wù)和性能信息溜歪。這提高了性能若专，因?yàn)樽粉櫞a直接注入到應(yīng)用程序代碼中。
在Pinpoint中蝴猪，API攔截部分和數(shù)據(jù)記錄部分是分開的调衰。攔截器被注入到我們想要追蹤的方法中膊爪，并調(diào)用before（）和after（）方法來處理數(shù)據(jù)記錄。通過字節(jié)碼增強(qiáng)嚎莉，Pinpoint Agent能夠只從必要的方法記錄數(shù)據(jù)米酬，這使得分析數(shù)據(jù)的大小變得緊湊。
Pinpoint Agent性能優(yōu)化
最后趋箩，我們將介紹如何優(yōu)化Pinpoint Agent的性能
使用二進(jìn)制格式(Thrift)
通過使用二進(jìn)制格式（Thrift）赃额，可以提高編碼速度。雖然它難以使用和調(diào)試叫确，但是通過減少生成的數(shù)據(jù)量可以提高網(wǎng)絡(luò)使用效率跳芳。
使用可變長(zhǎng)的編碼和格式優(yōu)化數(shù)據(jù)記錄
如果將一個(gè)長(zhǎng)整數(shù)轉(zhuǎn)換為固定長(zhǎng)度的字符串，則數(shù)據(jù)大小為8個(gè)字節(jié)竹勉。但是飞盆，如果使用可變長(zhǎng)度編碼，則數(shù)據(jù)大小可以在1到10個(gè)字節(jié)之間變化次乓，具體取決于給定數(shù)字的大小吓歇。為了減少數(shù)據(jù)大小，Pinpoint通過Thrift的Compact Protocol將數(shù)據(jù)編碼為可變長(zhǎng)度字符串檬输，并記錄要針對(duì)編碼格式進(jìn)行優(yōu)化的數(shù)據(jù)照瘾。Pinpoint Agent通過將基于根方法的剩余時(shí)間轉(zhuǎn)換為向量值來減少數(shù)據(jù)大小。
For more information on the variable-length encoding, see “Base 128 Varints” in Google Developers.
如圖4所示丧慈，為了得到3個(gè)不同的方法何時(shí)被調(diào)用并完成的信息析命，你需要測(cè)量6個(gè)不同點(diǎn)的時(shí)間。使用固定長(zhǎng)度編碼逃默，這個(gè)過程需要48個(gè)字節(jié)（6個(gè)點(diǎn)×8個(gè)字節(jié)）鹃愤。
同時(shí)，Pinpoint Agent使用可變長(zhǎng)度編碼完域，并根據(jù)相應(yīng)的格式記錄數(shù)據(jù)软吐。基于根方法的起始時(shí)間吟税，利用向量值的差值計(jì)算其他點(diǎn)的時(shí)間信息凹耙。因?yàn)橄蛄恐凳且粋€(gè)小數(shù)，所以它消耗少量的字節(jié)肠仪，結(jié)果只消耗13個(gè)字節(jié)肖抱，而不是48個(gè)字節(jié)。
如果執(zhí)行方法需要更多的時(shí)間异旧，那么即使使用可變長(zhǎng)度編碼意述，也會(huì)增加字節(jié)數(shù)。然而，它仍然比固定長(zhǎng)度編碼更有效荤崇。
用常量表替換重復(fù)的API信息拌屏，SQL語(yǔ)句和字符串
我們希望Pinpoint能夠做到代碼級(jí)別的追蹤。然而术荤，它在增加數(shù)據(jù)大小方面存在問題倚喂。每次向服務(wù)器發(fā)送高精度的數(shù)據(jù)時(shí)，由于數(shù)據(jù)的大小喜每，它增加了網(wǎng)絡(luò)使用率务唐。
為了解決這個(gè)問題雳攘，我們采用了在遠(yuǎn)程HBase服務(wù)器中創(chuàng)建常量表的策略带兜。由于每次都向Pinpoint Collector發(fā)送“methodA”的數(shù)據(jù)將會(huì)是一個(gè)負(fù)擔(dān)，因此Pinpoint Agent將“methodA”的數(shù)據(jù)轉(zhuǎn)換一個(gè)為ID吨灭，并將這個(gè)信息作為HBase中的常量表存儲(chǔ)刚照，并使用這個(gè)ID繼續(xù)追蹤數(shù)據(jù)。當(dāng)用戶在網(wǎng)站上檢索追蹤數(shù)據(jù)時(shí)喧兄，Pinpoint Web在常量表中搜索相應(yīng)ID的方法信息并重新組織它們无畔。使用同樣的方式來減少SQL語(yǔ)句的數(shù)據(jù)大小和頻繁使用的字符串的數(shù)據(jù)大小。
處理批量請(qǐng)求的樣本
Naver提供的在線門戶服務(wù)請(qǐng)求量非常龐大吠冤。單個(gè)服務(wù)每天處理超過200億個(gè)請(qǐng)求浑彰。跟蹤此類請(qǐng)求的一種簡(jiǎn)單的方法是：根據(jù)需要，擴(kuò)展網(wǎng)絡(luò)基礎(chǔ)架構(gòu)和服務(wù)器以滿足請(qǐng)求數(shù)量拯辙。但是郭变，這不是處理這種情況的經(jīng)濟(jì)有效的方法。在Pinpoint涯保，你可以只收集采樣數(shù)據(jù)而不必追蹤每一個(gè)請(qǐng)求诉濒。在請(qǐng)求很少的開發(fā)環(huán)境中，收集每個(gè)數(shù)據(jù)夕春。而在請(qǐng)求較大的生產(chǎn)環(huán)境中未荒，只收集到整個(gè)數(shù)據(jù)中的1~5%，足以分析整個(gè)應(yīng)用程序的狀態(tài)及志。通過采樣片排，可以最小化應(yīng)用程序中的網(wǎng)絡(luò)開銷，并降低網(wǎng)絡(luò)和服務(wù)器等基礎(chǔ)設(shè)施的成本速侈。
Pinpoint中的采樣方法
Pinpoint支持計(jì)數(shù)采樣率寡，如果設(shè)置為10，則它只收集10個(gè)請(qǐng)求中的1個(gè)請(qǐng)求的數(shù)據(jù)锌畸。我們計(jì)劃增加新的采樣器來更有效率的收集數(shù)據(jù)勇劣。
注：對(duì)應(yīng)的配置項(xiàng)在Pinpoint Agent的pinpoint.config文件中，默認(rèn)"profiler.sampling.rate=1"表示全部
使用異步數(shù)據(jù)傳輸來最小化應(yīng)用程序線程中止
pinpoint不干預(yù)應(yīng)用程序線程，因?yàn)榫幋a數(shù)據(jù)或遠(yuǎn)程消息是由另一個(gè)線程異步傳輸?shù)摹?/p>
通過UDP傳輸數(shù)據(jù)
與Google Dapper不同比默，Pinpoint通過網(wǎng)絡(luò)傳輸數(shù)據(jù)以確保數(shù)據(jù)速度幻捏。當(dāng)數(shù)據(jù)流量爆發(fā)時(shí)，與你的服務(wù)共享網(wǎng)絡(luò)可能是個(gè)問題命咐。在這種情況下篡九，Pinpoint Agent開始使用UDP協(xié)議為你的服務(wù)給出網(wǎng)絡(luò)連接的優(yōu)先級(jí)。
注意：數(shù)據(jù)傳輸API可以被替換醋奠，因?yàn)樗环蛛x為接口榛臼。它可以更改為以不同的存儲(chǔ)數(shù)據(jù)的實(shí)現(xiàn)方式，如本地文件窜司。
Pinpoint應(yīng)用示例
以下是如何從應(yīng)用程序中獲取數(shù)據(jù)的示例沛善，以便你可以全面了解前面描述的內(nèi)容。
圖5顯示了塞祈，當(dāng)你在TomcatA和TomcatB中安裝Pinpoint時(shí)可以看到的內(nèi)容金刁。你可以將單個(gè)節(jié)點(diǎn)的追蹤數(shù)據(jù)視為單個(gè)事務(wù)，它表示分布式事務(wù)追蹤的流议薪。
下面描述了Pinpoint為每個(gè)方法都做了什么：
1.當(dāng)請(qǐng)求到達(dá)TomcatA時(shí), Pinpoint Agent生成一個(gè)TraceId
①TX_ID: TomcatA^TIME^1
②SpanId: 10
③ParentSpanId: -1(Root)
2.從Spring MVC的控制器中記錄數(shù)據(jù)
3.干預(yù)HttpClient.execute()方法的調(diào)用尤蛮，并在HttpGet中配置TraceId
①創(chuàng)建一個(gè)子TraceId
②TX_ID: TomcatA^TIME^1 -> TomcatA^TIME^1
③SPAN_ID: 10 -> 20
④PARENT_SPAN_ID: -1 -> 10 (parent SpanId) - Configures the child TraceId in the HTTP header.
⑤HttpGet.setHeader(PINPOINT_TX_ID, “TomcatA^TIME^1”)
⑥HttpGet.setHeader(PINPOINT_SPAN_ID, “20”)
⑦HttpGet.setHeader(PINPOINT_PARENT_SPAN_ID, “10”)
4.傳輸打好Tag的請(qǐng)求傳輸?shù)絋omcatB
①TomcatB 檢查傳輸過來的請(qǐng)求的Header
②HttpServletRequest.getHeader(PINPOINT_TX_ID) - TomcatB在Header中標(biāo)識(shí)TraceId時(shí)成為了一個(gè)子節(jié)點(diǎn)
③TX_ID: TomcatA^TIME^1
④SPAN_ID: 20
⑤PARENT_SPAN_ID: 10
5.記錄來自Spring MVC控制器的數(shù)據(jù)并完成請(qǐng)求
①當(dāng)來自TomcatB的請(qǐng)求完成時(shí)，Pinpoint Agent將追蹤數(shù)據(jù)發(fā)送到Pinpoint Collector并將其存儲(chǔ)在HBase中斯议。
②來自TomcatB的HTTP調(diào)用結(jié)束以后产捞，來自TomcatA的請(qǐng)求也就完成了。Pinpoint Agent將追蹤數(shù)據(jù)發(fā)送到Pinpoint Collector并將其存儲(chǔ)在HBase中哼御。
③UI從HBase中讀取追蹤數(shù)據(jù)坯临，并通過排序成樹來創(chuàng)建調(diào)用堆棧。
結(jié)論
Pinpoint是另一個(gè)與應(yīng)用程序一起運(yùn)行的應(yīng)用程序艇搀。使用字節(jié)碼增強(qiáng)使得Pinpoint看起來不需要修改代碼尿扯。通常，字節(jié)碼增強(qiáng)技術(shù)使應(yīng)用程序更容易受風(fēng)險(xiǎn)的影響焰雕。如果Pinpoint中發(fā)生了問題衷笋，也會(huì)影響應(yīng)用程序。但是現(xiàn)在矩屁，我們并沒有消除這些威脅辟宗，而是集中精力改進(jìn)Pinpoint的性能和設(shè)計(jì)。因?yàn)槲覀冋J(rèn)為這使得Pinpoint更有價(jià)值吝秕。因此泊脐，是否使用Pinpoint由你決定。我們還是有大量的工作需要完成來改進(jìn)Pinpoint烁峭。盡管不完整容客，但Pinpoint還是作為開源項(xiàng)目發(fā)布了秕铛。我們將持續(xù)努力開發(fā)并改進(jìn)Pinpoint以便滿足你的期望。
Written by Woonduk Kang
2011年缩挑，我就這樣寫我自己——作為一名開發(fā)人員但两，我想制作一個(gè)用戶愿意付費(fèi)的軟件程序，像Microsoft或者Oracle供置。隨著Pinpoint作為一個(gè)開源項(xiàng)目推出谨湘，我的夢(mèng)想似乎有些成真。 目前芥丧，我的愿望是使Pinpoint對(duì)用戶更有價(jià)值和吸引力紧阔。
