應用效能管理の巔峰對決:Apache Skywalking P.K. Pinpoint
點選上方“芋道原始碼”,選擇“設為星標”
做積極的人,而不是積極廢人!
原始碼精品專欄
來源:http://t.cn/EIYZoDa
社群比較
支援語言比較
協議比較
儲存比較(重要)
UI比較
擴充套件性比較
告警比較
JVM監控
服務監控
跟蹤粒度比較
過濾追蹤
效能損耗
釋出包比較
支援元件比較
總結
參考連結
說明:本次對比基於skywalking-6.0.0-GA和Pinpoint-1.8.2(截止2019-02-19最新版本)。另外,我們這次技術選型直接否定了Zipkin,其最大原因是它對程式碼有侵入性,CAT也是一樣。這是我們所完全無法接受的。
這應該是目前最優秀的兩款開源APM產品了,而且兩款產品都通過位元組碼注入的方式,實現了對程式碼完全無任何侵入,他們的對比資訊如下:
OAP說明: skywalking6.x才有OAP這個概念,skywalking5.x叫collector。
接下來,對每個PK項進行深入分析和對比。
先來偷偷的做一個問卷調查,方便我們互相瞭解大家對 APM & 鏈路追蹤這塊的選型。
社群比較
這一點上面skywalking肯定完勝。一方面,skywalking已經進入apache孵化,社群相當活躍。而且專案發起人是中國人,我們能夠進入官方群(Apache SkyWalking交流群:392443393
)和專案發起人吳晟零距離溝通,很多問題能第一時間得到大家的幫助(玩過開源的都知道,這個價值有多大)。
而Pinpoint是韓國人開發的,免不了有溝通障礙。至於github上最近一年的commit頻率,skywalking和Pinpoint旗鼓相當,都是接近20的水平:
所以,社群方面,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真是無所不在。
UI比較
Pinpoint的UI確實比skywalking稍微好些,尤其是服務的拓撲圖展示。不過daocloud根據Pinpoint的風格為skywalking定製了一款UI。請戳連結:https://github.com/TinyAllen/rocketbot,專案介紹是: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還支援多個指標同一時間點檢視的功能。如下圖所示:
所以,對JVM的監控方面,Pinpoint更勝一籌。
服務監控
包括作業系統,和部署的服務例項的監控。
Pinpoint支援的維度有:CPU使用率,Open File Descriptor,資料來源,活動執行緒數,RT,TPS。
skywalking支援的維度有:CPU使用率,SLA,RT,CPM(Call Per Minutes)。
所以,這方面兩者旗鼓相當,沒有明顯的差距。
跟蹤粒度比較
Pinpoint在這方面做的非常好,跟蹤粒度非常細。如下圖所示,是Pinpoint對某個介面的trace資訊:
而同一個介面skywalking的trace資訊如下圖所示:
備註: 此截圖是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支援的中介軟體對比說明:
WEB容器說明:Pinpoint支援幾乎所有的WEB容器,包括開源和商業的。而wkywalking只支援開源的WEB容器,對2款大名鼎鼎的商業WEB容器Weblogic和Wevsphere都不支援。
RPC框架說明:對RPC框架的支援,skywalking簡直秒殺Pinpoint。連小眾的motan和sofarpc都支援。
MQ說明:skywalking比Pinpoint多支援一個國產的MQ中介軟體RocketMQ,畢竟RocketMQ在國內名氣大,而在國外就一般了。加之skywalking也是國產的。
RDBMS/NoSQL說明:Pinpoint對RDBMS和NoSQL的支援都要略好於skywalking,RDBMS方面,skywalking不支援MSSQL和MariaDB。而NoSQL方面,skywalking不支援Cassandra和HBase。至於Pinpoint不支援的H2,完全不是問題,畢竟生產環境是肯定不會使用H2作為底層儲存的。
Redis客戶端說明:雖然skywalking和Pinpoint都支援Redis,但是skywalking支援三種流行的Redis客戶端:Jedis,Redisson,Lettuce。而Pinpoint只支援Jedis和Lettuce,再一次,韓國人開發的Pinpoint無視了目前中國人開發的GitHub上star最多的Redis Client -- Redisson。
日誌框架說明: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
歡迎加入我的知識星球,一起探討架構,交流原始碼。加入方式,長按下方二維碼噢:
已在知識星球更新原始碼解析如下:
如果你喜歡這篇文章,喜歡,轉發。
生活很美好,明天見(。・ω・。)ノ♡
相關文章
- F5應用交付容器解決方案如何?看這場巔峰對決
- 針對運營商行業的虛擬化應用效能監測管理解決方案行業
- 聯想Z5 Pro GT與榮耀Magic2區別對比:效能巔峰對決 哪款好?
- Flutter和原生應用效能對比Flutter
- 使用python3抓取pinpoint應用資訊入庫Python
- 晚上の決心
- 分散式應用追蹤系統 - Skywalking分散式
- 三國爭霸 Mint、Ubuntu 和 Red Hat 巔峰對決Ubuntu
- 巔峰對決,第四屆全球資料庫大賽—PolarDB效能挑戰賽圓滿收官資料庫
- 效能魔方mmTrix全球領先,提供完整雲應用效能管理
- Apache配置與應用Apache
- Apache SkyWalking在windows機器上的實踐ApacheWindows
- 詳解 Apache SkyWalking OAP 的分散式計算Apache分散式
- 2020應用效能管理預測(一)
- Pinpoint 編譯環境搭建(Pinpoint系列一)編譯
- Apache Pulsar 與 Apache Kafka 在金融場景下的效能對比分析ApacheKafka
- SkyWalking —— 分散式應用監控與鏈路追蹤分散式
- Node.js應用接入Skywalking實現APM監控Node.js
- 檢測和解決Android應用的效能問題Android
- 效能魔方mmTrix雲應用效能管理,助力客戶提升使用者體驗
- SRE 彈效能力:使用 Envoy 對應用進行速率限制
- Apache Hudi在Hopworks機器學習的應用Apache機器學習
- Android 設計模式の單例模式——應用最廣的模式Android設計模式單例
- 對PDM產品資料管理應用與發展
- 巔峰對話——圖靈獎得主共話機器學習圖靈機器學習
- ALB Ingress 釋出!輕鬆應對雲原生應用流量管理
- 年底考勤管理彙總難?新一代OA管理系統無縫對接外部應用助你解決
- [Apache][Nginx]構建僅對團隊內部公開使用的web應用ApacheNginxWeb
- Apache Hudi典型應用場景知多少?Apache
- 調優 | Apache Hudi應用調優指南Apache
- Apache Kafka在沃爾瑪的應用ApacheKafka
- Apache Flink 在蔚來汽車的應用Apache
- 聯想公司專案風險管理解決方案及應用
- 教育行業SaaS應用管理平臺解決方案行業
- 企業網際網路應用高效能解決之道
- 使用 Dynatrace 對 Node.js 應用的效能資料進行分析Node.js
- Apache 與 Nginx 效能對比:Web 伺服器優化技術ApacheNginxWeb伺服器優化
- 《高效能iOS 應用開發》之影響移動應用效能的因素iOS