歡迎光臨
每天分享高質量文章

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

  • 社區比較
  • 支持語言比較
  • 協議比較
  • 儲存比較(重要)
  • UI比較
  • 擴展性比較
  • 告警比較
  • JVM監控
  • 服務監控
  • 跟蹤粒度比較
  • 過濾追蹤
  • 性能損耗
  • 發佈包比較
  • 支持組件比較
  • 總結
  • 參考鏈接

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

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

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的水平:

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真是無所不在。

skywalking trace query

UI比較

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

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還支持多個指標同一時間點查看的功能。如下圖所示:

Pinpoint JVM inspector

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

服務監控

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

跟蹤粒度比較

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

Pinpoint trace detail

而同一個接口skywalking的trace信息如下圖所示:

skywalking trace detail
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預設策略比較保守,對性能損耗很小。
有網友做過壓力測試,對比如下:

壓力測試

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

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

發佈包比較

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

所以,在發佈包方面,skywalking更勝一籌

支持組件比較

支持組件對比

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

赞(0)

分享創造快樂