應用效能管理の巔峰對決:Apache Skywalking P.K. Pinpoint

芋道原始碼發表於2019-03-08

點選上方“芋道原始碼”,選擇“設為星標

做積極的人,而不是積極廢人!

原始碼精品專欄

 

來源:http://t.cn/EIYZoDa

  • 社群比較

  • 支援語言比較

  • 協議比較

  • 儲存比較(重要)

  • UI比較

  • 擴充套件性比較

  • 告警比較

  • JVM監控

  • 服務監控

  • 跟蹤粒度比較

  • 過濾追蹤

  • 效能損耗

  • 釋出包比較

  • 支援元件比較

  • 總結

  • 參考連結


說明:本次對比基於skywalking-6.0.0-GA和Pinpoint-1.8.2(截止2019-02-19最新版本)。另外,我們這次技術選型直接否定了Zipkin,其最大原因是它對程式碼有侵入性,CAT也是一樣。這是我們所完全無法接受的。

這應該是目前最優秀的兩款開源APM產品了,而且兩款產品都通過位元組碼注入的方式,實現了對程式碼完全無任何侵入,他們的對比資訊如下:

640?wx_fmt=jpeg
Pinpoint P.K. skywalking

OAP說明: skywalking6.x才有OAP這個概念,skywalking5.x叫collector。

接下來,對每個PK項進行深入分析和對比。

先來偷偷的做一個問卷調查,方便我們互相瞭解大家對 APM & 鏈路追蹤這塊的選型。

社群比較

這一點上面skywalking肯定完勝。一方面,skywalking已經進入apache孵化,社群相當活躍。而且專案發起人是中國人,我們能夠進入官方群(Apache SkyWalking交流群:392443393)和專案發起人吳晟零距離溝通,很多問題能第一時間得到大家的幫助(玩過開源的都知道,這個價值有多大)。
而Pinpoint是韓國人開發的,免不了有溝通障礙。至於github上最近一年的commit頻率,skywalking和Pinpoint旗鼓相當,都是接近20的水平:

640?wx_fmt=jpeg
Insight commit

所以,社群方面,skywalking更勝一籌。

支援語言比較

Pinpoint只支援Java和PHP,而skywalking支援4種語言:Java, C#, PHP, Node.js。如果公司的服務涉及到多個開發語言,那麼skywalking會是你更好的選擇。並且,如果你要實現自己的探針(比如Go語言),skywalking的二次開發成本也比Pinpoint更低。

說明:Github上有開發者為Pinpoint貢獻了對Node.js的支援,請戳連結:https://github.com/peaksnail/pinpoint-node-agent。但是已經停止維護,幾年沒更新了!

所以,支援語言方面,skywalking更勝一籌

協議比較

SkyWalking支援gRPC和http,不過建議使用gRPC,skywalking6.x版本已經不提供http方式(但是還會保留接收5.x的資料),以後會考慮刪除。
而Pinpoint使用的是thrift協議。
協議本身沒有誰好誰壞。

儲存比較(重要)

筆者認為,儲存是skywalking和Pinpoint最大的差異所在,因為底層儲存決定了上層功能。
Pinpoint只支援HBase,且擴充套件代價較大。這就意味著,如果選擇Pinpoint,還要有能力hold住一套HBase叢集(daocloud從Pinpoint切換到skywalking就是因為HBase的維護代價有點大)。在這方面,skywalking支援的儲存就多很多,這樣的話,技術選型時可以根據團隊技術特點選擇合適的儲存,而且還可以自行擴充套件(不過生產環境上應該大部分是以es儲存為主)。
Pinpoint只支援HBase的另一個缺陷就是,HBase本身查詢能力有限(HBase只能支援三種方式查詢:RowKey精確查詢,SCAN範圍查詢,全表掃描)限制了Pinpoint的查詢能力,所以其支援的查詢一定是在時間的基礎上(Pinpoint通過滑鼠圈定一個時間範圍後檢視這個範圍內的Trace資訊)。而skywalking可以多個維度任意組合查詢,例如:時間範圍,服務名,Trace狀態,請求路徑,TraceId等。

另外,Pinpoint和skywalking都支援TTL,即歷史資料保留策略。skywalking是在OAP模組的application.yml中配置從而指定保留時間。而Pinpoint是通過HBase的ttl功能實現,通過Pinpoint提供的hbase指令碼https://github.com/naver/pinpoint/blob/master/hbase/scripts/hbase-create.hbase可以看到:ApplicationTraceIndex配置了TTL => 5184000,SqlMetaData_Ver2配合了TTL => 15552000,單位是秒。

說明:es並不是完全碾壓HBase,es和HBase沒有絕對的好和壞。es強在檢索能力,儲存能力偏弱。HBase強在儲存能力,檢索能力偏弱。如果蒐集的日誌量非常龐大,那麼es儲存就比較吃力。同樣的,如果對檢索能力有一定的要求,那麼HBase肯定滿足不了你。所以,又到了根據你的業務和需求決定的時刻了,trade-off真是無所不在。

640?wx_fmt=jpeg
skywalking trace query

UI比較

Pinpoint的UI確實比skywalking稍微好些,尤其是服務的拓撲圖展示。不過daocloud根據Pinpoint的風格為skywalking定製了一款UI。請戳連結:https://github.com/TinyAllen/rocketbot,專案介紹是:rocketbot: A UI for Skywalking。截圖如下所示;

640?wx_fmt=jpeg
rocketbot: A UI for Skywalking

所以,只比較原生UI的話,Pinpoint更勝一籌。

擴充套件性比較

Pinpoint好像設計之初就沒有過多考慮擴充套件性,無論是底層的儲存,還是自定義探針實現等。而skywalking核心設計目標之一就是Pluggable,即可插拔。
以儲存為例,pinpoint完全沒有考慮擴充套件性,而skywalking如果要自定義實現一套儲存,只需要定義一個類實現介面org.apache.skywalking.oap.server.library.module.ModuleProvider,然後實現一些DAO即可。至於Pinpoint則完全沒有考慮過擴充套件底層儲存。
再以實現一個自己的探針為例(比如我要實現Go語言的探針),Pinpoint選擇thrift作為資料傳輸協議標準,而且為了節省資料傳輸大小,在傳遞常量的時候也儘量使用資料參考字典,傳遞一個數字而不是直接傳遞字串等等。這些優化也增加了系統的複雜度:包括使用 Thrift 介面的難度、UDP 資料傳輸的問題、以及資料常量字典的註冊問題等等。Pinpoint發展這麼年才支援Java和PHP,可見一斑。而skywalking的資料介面就標準很多,並且支援OpenTracing協議,除了官方支援Java以外,C#、PHP和Node.js的支援都是由社群開發並維護。
還有後面會提到的告警,skywalking的可擴充套件性也要遠好於Pinpoint。
最後,Pinpoint和skywalking都支援外掛開發,Pinpoint外掛開發參考:http://naver.github.io/pinpoint/1.8.2/plugindevguide.html。skywalking外掛開發參考:https://github.com/apache/incubator-skywalking/blob/master/docs/en/guides/Java-Plugin-Development-Guide.md。

所以,擴充套件性方面skywalking更勝一籌

告警比較

Pinpoint和skywalking都支援自定義告警規則。

但是惱人的是,Pinpoint如果要配置告警規則,還需要安裝MySQL(配置告警時的使用者,使用者組資訊以及告警規則都持久化儲存在MySQL中),這就導致Pinpoint的維護成本又高了一些,既要維護HBase又要維護MySQL。

Pinpoint支援的告警規則有:SLOW COUNT|RATE, ERROR COUNT|RATE, TOTAL COUNT, SLOW COUNT|RATE TO CALLEE, ERROR COUNT|RATE TO CALLEE, ERROR RATE TO CALLEE, HEAP USAGE RATE, JVM CPU USAGE RATE, DATASOURCE CONNECTION USAGE RATE。

Pinpoint每3分鐘週期性檢查過去5分鐘的資料,如果有符合規則的告警,就會傳送sms/email給使用者組下的所有使用者。需要說明的是,實現傳送sms/email的邏輯需要自己實現,Pinpoint只提供了介面com.navercorp.pinpoint.web.alarm.AlarmMessageSender。並且Pinpoint發現告警持續時,會遞增傳送sms/email的時間間隔 3min -> 6min -> 12min -> 24min,防止sms/email狂刷。

Pinpoint告警參考:http://naver.github.io/pinpoint/1.8.2/alarm.html

skywalking配置告警不需要引入任何其他儲存。skywalking在config/alarm-settings.xml中可以配置告警規則,告警規則支援自定義。

skywalking支援的告警規則(配置項中的名稱是indicator-name)有:service_resp_time, service_sla, service_cpm, service_p99, service_p95, service_p90, service_p75, service_p50, service_instance_sla, service_instance_resp_time, service_instance_cpm, endpoint_cpm, endpoint_avg, endpoint_sla, endpoint_p99, endpoint_p95, endpoint_p90, endpoint_p75, endpoint_p50。

Skywalking通過HttpClient的方式遠端呼叫在配置項webhooks中定義的告警通知服務地址。skywalking也支援silence-period配置,假設在TN這個時間點觸發了告警,那麼TN -> TN+period 這段時間內不會再重複傳送該告警。

skywalking告警參考:https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/backend/backend-alarm.md。目前只支援official_analysis.oal指令碼中Service, Service Instance, Endpoint scope的metric,其他scope的metric需要等待後續擴充套件。

Pinpoint和skywalking都支援常用的告警規則配置,但是skywalking採用webhooks的方式就靈活很多:簡訊通知,郵件通知,微信通知都是可以支援的。而Pinpoint只能sms/email通知,並且還需要引入MySQL儲存,增加了整個系統複雜度。所以,告警方面,skywalking更勝一籌

JVM監控

skywalking支援監控:Heap, Non-Heap, GC(YGC和FGC)。
Pinpoint能夠監控的指標主要有:Heap, Non-Heap, FGC, DirectBufferMemory, MappedBufferMemory,但是沒有YGC。另外,Pinpoint還支援多個指標同一時間點檢視的功能。如下圖所示:

640?wx_fmt=jpeg
Pinpoint JVM inspector

所以,對JVM的監控方面,Pinpoint更勝一籌。

服務監控

包括作業系統,和部署的服務例項的監控。
Pinpoint支援的維度有:CPU使用率,Open File Descriptor,資料來源,活動執行緒數,RT,TPS。
skywalking支援的維度有:CPU使用率,SLA,RT,CPM(Call Per Minutes)。
所以,這方面兩者旗鼓相當,沒有明顯的差距。

跟蹤粒度比較

Pinpoint在這方面做的非常好,跟蹤粒度非常細。如下圖所示,是Pinpoint對某個介面的trace資訊:

640?wx_fmt=jpeg
Pinpoint trace detail

而同一個介面skywalking的trace資訊如下圖所示:

640?wx_fmt=jpeg
skywalking trace detail
640?wx_fmt=jpeg
skywalking trace sql

備註: 此截圖是skywalking載入了外掛apm-spring-annotation-plugin-6.0.0-GA.jar(這個外掛允許跟蹤加了@Bean, @Service, @Component and @Repository註解的spring context中的bean的方法)。

通過對比發現,在跟蹤粒度方面,Pinpoint更勝一籌

過濾追蹤

Pinpoint和skywalking都可以實現,而且配置的表示式都是基於ant風格。
Pinpoint在Web UI上配置 filter wizard 即可自定義過濾追蹤。
skywalking通過載入apm-trace-ignore-plugin外掛就能自定義過濾跟蹤,skywalking這種方式更靈活,比如一臺高配伺服器上有若干個服務,在共用的agent配置檔案apm-trace-ignore-plugin.config中可以配置通用的過濾規則,然後通過-D的方式為每個服務配置個性化過濾。

所以,在過濾追蹤方面,skywalking更勝一籌

效能損耗

由於Pinpoint採集資訊太過詳細,所以,它對效能的損耗最大。而skywalking預設策略比較保守,對效能損耗很小。
有網友做過壓力測試,對比如下:

640?wx_fmt=jpeg
壓力測試

圖片來源於:https://juejin.im/post/5a7a9e0af265da4e914b46f1

所以,在效能損耗方面,skywalking更勝一籌

釋出包比較

skywalking與時俱進,全系標配jar包,部署只需要執行start.sh指令碼即可。而Pinpoint的collector和web還是war包,部署時依賴web容器(比如Tomcat)。拜託,都9012年了。

所以,在釋出包方面,skywalking更勝一籌

支援元件比較

640?wx_fmt=jpeg
支援元件對比

skywalking和Pinpoint支援的中介軟體對比說明:

  1. WEB容器說明:Pinpoint支援幾乎所有的WEB容器,包括開源和商業的。而wkywalking只支援開源的WEB容器,對2款大名鼎鼎的商業WEB容器Weblogic和Wevsphere都不支援。

  2. RPC框架說明:對RPC框架的支援,skywalking簡直秒殺Pinpoint。連小眾的motan和sofarpc都支援。

  3. MQ說明:skywalking比Pinpoint多支援一個國產的MQ中介軟體RocketMQ,畢竟RocketMQ在國內名氣大,而在國外就一般了。加之skywalking也是國產的。

  4. RDBMS/NoSQL說明:Pinpoint對RDBMS和NoSQL的支援都要略好於skywalking,RDBMS方面,skywalking不支援MSSQL和MariaDB。而NoSQL方面,skywalking不支援Cassandra和HBase。至於Pinpoint不支援的H2,完全不是問題,畢竟生產環境是肯定不會使用H2作為底層儲存的。

  5. Redis客戶端說明:雖然skywalking和Pinpoint都支援Redis,但是skywalking支援三種流行的Redis客戶端:Jedis,Redisson,Lettuce。而Pinpoint只支援Jedis和Lettuce,再一次,韓國人開發的Pinpoint無視了目前中國人開發的GitHub上star最多的Redis Client -- Redisson。

  6. 日誌框架說明:Pinpoint居然不支援log4j2?但是已經有人開發了相關功能,詳情請戳連結:log4j plugin support log4j2 or not? https://github.com/naver/pinpoint/issues/3055


通過對skywalking和Pinpoint支援中介軟體的對比我們發現,skywalking對國產軟體的支援真的是全方位秒殺Pinpoint,比如小眾化的RPC框架:motan(微博出品),sofarpc,阿里的RocketMQ,Redis客戶端Redisson,以及分散式任務排程框架elastic-job等。當然也從另一方面反應國產開源軟體在世界上的影響力還很小。

這方面沒有誰好誰壞,畢竟每個公司使用的技術棧不一樣。如果你對RocketMQ有強需求,那麼skywalking是你的最佳選擇。如果你對es有強需求,那麼skywalking也是你的最佳選擇。如果HBase是你的強需求,那麼Pinpoint就是你的最佳選擇。如果MSSQL是你的強需求,那麼Pinpoint也是你的最佳選擇。總之,這裡完全取決你的專案了。


總結

經過前面對skywalking和Pinpoint全方位對比後我們發現,對於兩款非常優秀的APM軟體,有一種既生瑜何生亮的感覺。Pinpoint的優勢在於:追蹤資料粒度非常細、功能強大的使用者介面,以及使用HBase作為儲存帶來的海量儲存能力。而skywalking的優勢在於:非常活躍的中文社群,支援多種語言的探針,對國產開源軟體非常全面的支援,以及使用es作為底層儲存帶來的強大的檢索能力,並且skywalking的擴充套件性以及定製化要更優於Pinpoint:

  • 如果你有海量的日誌儲存需求,推薦Pinpoint。

  • 如果你更看重二次開發的便捷性,推薦skywalking。

最後,參考上面的對比,結合你的需求,哪些不能妥協,哪些可以捨棄,從而更好的選擇一款最適合你的APM軟體。

參考連結

  • 參考[1]. https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md

  • 參考[2]. http://naver.github.io/pinpoint/1.8.2/main.html#supported-modules

  • 參考[3]. https://juejin.im/post/5a7a9e0af265da4e914b46f1




歡迎加入我的知識星球,一起探討架構,交流原始碼。加入方式,長按下方二維碼噢

640?wx_fmt=jpeg

已在知識星球更新原始碼解析如下:

640?wx_fmt=png

640?wx_fmt=png

640?wx_fmt=png

如果你喜歡這篇文章,喜歡,轉發。

生活很美好,明天見(。・ω・。)ノ♡

相關文章